フロントとバックで事情は結構異なるけど、言いたいことはわかる気がする
インメモリなリポジトリを定義すれば殆どのケースは外部アクセスなしで完結するので高速です。外部アクセスを伴った統合/E2Eテストは分けて管理しリリース前などの必要なタイミングで走らせれば快適です。
DIPの段落には全く同意できない
読んでて全然わからなかったんだけど、結局ユニットテストがしやすいコード構成は…？ユースケースとコントローラを分けるって話？
｢なるほど、抽象が適切でないんじゃないんですか？｣
すみません、TypescriptでJavaから劣化移植したような設計するのもうやめません？って思いました。。。本当にclassの存在意義が見出せない。
現代的なwebアプリのバックエンドだとDI対象を引数で受け取ってハンドラ関数返すクロージャ作るだけで十分だろ
ユニットテストがしやすいコード構成について過去を振り返って考えてみた
フロントとバックで事情は結構異なるけど、言いたいことはわかる気がする
インメモリなリポジトリを定義すれば殆どのケースは外部アクセスなしで完結するので高速です。外部アクセスを伴った統合/E2Eテストは分けて管理しリリース前などの必要なタイミングで走らせれば快適です。
DIPの段落には全く同意できない
読んでて全然わからなかったんだけど、結局ユニットテストがしやすいコード構成は…？ユースケースとコントローラを分けるって話？
｢なるほど、抽象が適切でないんじゃないんですか？｣
すみません、TypescriptでJavaから劣化移植したような設計するのもうやめません？って思いました。。。本当にclassの存在意義が見出せない。
現代的なwebアプリのバックエンドだとDI対象を引数で受け取ってハンドラ関数返すクロージャ作るだけで十分だろ