ユニットテストがしやすいコード構成について過去を振り返って考えてみた

はじめに インテグレーションテスト主体でテストを書いていく場合、テスト実行時間が長い問題が出てきた。 （インスタンスをたくさん並べてパラレル実行にするとかやりようはあると思う） 解決するためには出来る限りユニットテストに寄せた方が良いが、どういったコード構成ならユニットテストに寄せやすいのか？考えた。 今あるアーキテクチャから選べばいいじゃんという話もあるが。。。 既存アーキテクチャだとなんかしっくりこないのでしっくりくるのを考えてみた。 全部に当てはまる正解はないので、自分の関わってきたシステムを振り返り、それらを踏まえて考えてみる。 実際に本番稼働していたシステムを元に考えるので本番稼働できるものにはなると思う。 あくまで自分基準での話にはなるので過度な期待はしないでください。 自分のWeb開発はJavaからスタートした話 日立のJP1Scriptが最初の仕事だったけど、Webシステム

[w1234567]

現代的なwebアプリのバックエンドだとDI対象を引数で受け取ってハンドラ関数返すクロージャ作るだけで十分だろ

[hirokinko]

すみません、TypescriptでJavaから劣化移植したような設計するのもうやめません？って思いました。。。本当にclassの存在意義が見出せない。

[sd-craft]

｢なるほど、抽象が適切でないんじゃないんですか？｣

[chiroruxx]

読んでて全然わからなかったんだけど、結局ユニットテストがしやすいコード構成は…？ユースケースとコントローラを分けるって話？

[Error401]

DIPの段落には全く同意できない

[soxandcity]

インメモリなリポジトリを定義すれば殆どのケースは外部アクセスなしで完結するので高速です。外部アクセスを伴った統合/E2Eテストは分けて管理しリリース前などの必要なタイミングで走らせれば快適です。

[diveintounlimit]

フロントとバックで事情は結構異なるけど、言いたいことはわかる気がする