unit-testing - 単体テストが難しいコードを書く

Question

あるインタビューで、「コードを単体テストしにくくするにはどうすればよいですか?」という質問をされました。密結合のコードを書くことについてつぶやいてしまいました。この質問に対する正しい答え/アプローチを教えてください。

Answer 1

Mishko's Guide: Writing Testable Codeを見て、これらの欠陥をできるだけ多くコードに導入すると、テスト不可能なコードになってしまいます。

例えば：

• コンストラクターでできる限りのことを行い、スレッドを開始し、ループと ifs を使用します
• メソッド呼び出しの長いチェーンを作成してデメテルの法則を破る
• どこでもシングルトンを使用し、依存関係を要求せず、静的プロバイダーでそれらを検索します
• 2,000 行のコードで神のクラスを作成する

Answer 2

• 演算子を使用してクラスに必要な依存関係newを自分で作成するだけで十分です! これは、あなたの答えである密結合コードを意味します。
• SOLIDの原則に従わないコード。

Mockしたがって、テストでは、依存関係を自分で作成し、関係をハードコーディングしているため、オブジェクトを使用できません。

依存性注入を使用すると、ポリモーフィックな動作を使用できるため、コンストラクターまたはメソッドで渡された依存関係でメソッドを呼び出すクラスは、具象型を知る必要がありません。したがって、テストではモック オブジェクトを渡すことができ、クラスを簡単にテストできます。

Misko のテスト可能なコードの作成では、テスト不可能なコードを作成することが得意であり、それを解決する方法について説明しています。

例 (JAVA):

//hard to unit test this code as testing class A also requires that ClassB should work properly
//What is ClassB does some I/O or DB operations. This makes unit test a integration test
class classA{
   ClassB b = new ClassB();   //Creating concrete dependencies

}

interface B{
     //implemented by Class B and your mock class that you create for testing
}

class ClassA{
     private B b;

     //Here you can use mocking framework or create a mock class yourself and pass that as argument
     //So the mock class will not do any DB or I/O and makes this unit test
     public classA(B b){
         this.b = b;
     }
}