ファイルシステムに依存するコードの単体テスト

私は、ZIPファイルを指定した場合に必要なコンポーネントを作成しています。

1. ファイルを解凍します。
2. 解凍したファイルから特定のdllを見つけます。
3. リフレクションを介してそのdllをロードし、その上でメソッドを呼び出します。

このコンポーネントを単体テストしたいのですが。

ファイルシステムを直接処理するコードを作成したくなります。

void DoIt()
{
   Zip.Unzip(theZipFile, "C:\\foo\\Unzipped");
   System.IO.File myDll = File.Open("C:\\foo\\Unzipped\\SuperSecret.bar");
   myDll.InvokeSomeSpecialMethod();
}

しかし、「ファイルシステム、データベース、ネットワークなどに依存する単体テストを記述しないでください」とよく言われます。

これをユニットテストに適した方法で書くとすると、次のようになると思います。

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

わーい！今ではテスト可能です。DoItメソッドにテストダブル（モック）をフィードできます。しかし、どのようなコストで？これをテスト可能にするためだけに、3つの新しいインターフェースを定義する必要がありました。そして、正確には何をテストしていますか？私のDoIt関数がその依存関係と適切に相互作用することをテストしています。zipファイルが適切に解凍されたことなどはテストしません。

もう機能をテストしているような気がしません。クラスの相互作用をテストしているような感じです。

私の質問はこれです：ファイルシステムに依存する何かを単体テストする適切な方法は何ですか？

編集私は.NETを使用していますが、この概念はJavaまたはネイティブコードにも適用できます。

これには本当に何も問題はありません。それは、単体テストと統合テストのどちらを呼び出すかという問題です。ファイルシステムを操作する場合は、意図しない副作用がないことを確認する必要があります。具体的には、自分でクリーンアップすること、作成した一時ファイルを削除すること、および使用していた一時ファイルと同じファイル名を持つ既存のファイルを誤って上書きしないことを確認してください。絶対パスではなく、常に相対パスを使用してください。

またchdir()、テストを実行する前に一時ディレクトリに移動し、chdir()その後に戻ることもお勧めします。

わーい！今ではテスト可能です。DoItメソッドにテストダブル（モック）をフィードできます。しかし、どのようなコストで？これをテスト可能にするためだけに、3つの新しいインターフェースを定義する必要がありました。そして、正確には何をテストしていますか？私のDoIt関数がその依存関係と適切に相互作用することをテストしています。zipファイルが適切に解凍されたことなどはテストしません。

爪を頭に当てました。テストしたいのはメソッドのロジックであり、必ずしも実際のファイルをアドレス指定できるかどうかではありません。ファイルが正しく解凍されているかどうかを（この単体テストで）テストする必要はありません。メソッドはそれを当然と見なします。インターフェースは、1つの具体的な実装に暗黙的または明示的に依存するのではなく、プログラミング対象の抽象化を提供するため、それ自体が貴重です。

あなたの質問は、開発者がそれに入るだけのテストの最も難しい部分の1つを明らかにします。

「一体何をテストするの？」

あなたの例は、いくつかのAPI呼び出しを接着するだけなので、それほど興味深いものではありません。そのため、単体テストを作成する場合、メソッドが呼び出されたことを表明するだけです。このようなテストは、実装の詳細をテストに密接に結び付けます。メソッドの実装の詳細を変更するたびにテストを変更する必要があるため、実装の詳細を変更するとテストが中断されるため、これは悪いことです。

悪いテストがあることは、実際にテストがないことよりも悪いです。

あなたの例では：

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner)
{
   string path = zipper.Unzip(theZipFile);
   IFakeFile file = fileSystem.Open(path);
   runner.Run(file);
}

モックを渡すことはできますが、テストするメソッドにロジックはありません。このための単体テストを試みると、次のようになります。

// Assuming that zipper, fileSystem, and runner are mocks
void testDoIt()
{
  // mock behavior of the mock objects
  when(zipper.Unzip(any(File.class)).thenReturn("some path");
  when(fileSystem.Open("some path")).thenReturn(mock(IFakeFile.class));

  // run the test
  someObject.DoIt(zipper, fileSystem, runner);

  // verify things were called
  verify(zipper).Unzip(any(File.class));
  verify(fileSystem).Open("some path"));
  verify(runner).Run(file);
}

おめでとうございます。基本的に、DoIt()メソッドの実装の詳細をテストにコピーアンドペーストしました。維持してください。

テストを作成するときは、HOWではなくWHATをテストする必要があります。 詳細については、ブラックボックステストを参照してください。

WHATあなたのメソッドの名前である（あるいは少なくともそれはする必要があります）。どのようにすべてのあなたの方法の内側に住む小さな実装の詳細です。優れたテストでは、WHATを壊すことなくHOWを交換できます。

このように考えて、自問してみてください。

「（パブリックコントラクトを変更せずに）このメソッドの実装の詳細を変更すると、テストが失敗しますか？」

答えが「はい」の場合は、WHATではなくHOWをテストしています。

ファイルシステムの依存関係を使用したコードのテストに関する特定の質問に答えるために、ファイルで少し興味深いことがあり、Base64でエンコードされたコンテンツをbyte[]ファイルに保存したいとします。これにストリームを使用して、コードがどのように動作するかを確認する必要なく、コードが正しいことをテストできます。1つの例は次のようなものです（Javaの場合）：

interface StreamFactory {
    OutputStream outStream();
    InputStream inStream();
}

class Base64FileWriter {
    public void write(byte[] contents, StreamFactory streamFactory) {
        OutputStream outputStream = streamFactory.outStream();
        outputStream.write(Base64.encodeBase64(contents));
    }
}

@Test
public void save_shouldBase64EncodeContents() {
    OutputStream outputStream = new ByteArrayOutputStream();
    StreamFactory streamFactory = mock(StreamFactory.class);
    when(streamFactory.outStream()).thenReturn(outputStream);

    // Run the method under test
    Base64FileWriter fileWriter = new Base64FileWriter();
    fileWriter.write("Man".getBytes(), streamFactory);

    // Assert we saved the base64 encoded contents
    assertThat(outputStream.toString()).isEqualTo("TWFu");
}

テストではaを使用しますByteArrayOutputStreamが、アプリケーションでは（依存関係の注入を使用して）実際のStreamFactory（おそらくFileStreamFactoryと呼ばれる）はFileOutputStreamから戻りoutputStream()、に書き込みFileます。

writeここでのメソッドの興味深い点は、Base64でエンコードされたコンテンツを書き込むことでした。そのため、これをテストしました。あなたのDoIt()方法では、これは統合テストでより適切にテストされます。

私は、ユニットテストを容易にするためだけに存在するタイプと概念でコードを汚染するのに抵抗しています。確かに、それによってデザインがよりクリーンで優れたものになれば、それはよくないことだと思います。

これについての私の見解は、あなたの単体テストはできる限り多くのことをするでしょう、それは100％のカバレッジではないかもしれません。実際、それは10％に過ぎないかもしれません。ポイントは、ユニットテストは高速で、外部依存関係がないことです。「このパラメーターにnullを渡すと、このメソッドはArgumentNullExceptionをスローする」などのケースをテストする場合があります。

次に、外部依存関係を持つことができる統合テスト（自動化され、おそらく同じユニットテストフレームワークを使用）を追加し、これらのようなエンドツーエンドのシナリオをテストします。

コードカバレッジを測定するときは、単体テストと統合テストの両方を測定します。

ファイルシステムにアクセスしても問題はありません。単体テストではなく、統合テストと考えてください。ハードコードされたパスを相対パスに交換し、単体テストのzipを含むTestDataサブフォルダーを作成します。

統合テストの実行に時間がかかりすぎる場合は、それらを分離して、クイック単体テストほど頻繁に実行されないようにします。

私は同意します。ときどき、相互作用ベースのテストはカップリングが多すぎて、十分な価値が得られないことが多いと思います。ここでファイルの解凍をテストしたいのは、正しいメソッドを呼び出していることを確認するだけではありません。

1つの方法は、InputStreamを取得するunzipメソッドを記述することです。次に、単体テストは、ByteArrayInputStreamを使用してバイト配列からそのようなInputStreamを構築できます。そのバイト配列の内容は、単体テストコードでは定数になる可能性があります。

理論的には、変更される可能性のある特定の詳細（ファイルシステム）に依存しているため、これは統合テストのようです。

OSを処理するコードを独自のモジュール（クラス、アセンブリ、jarなど）に抽象化します。特定のDLLが見つかった場合はそれをロードする場合は、IDllLoaderインターフェイスとDllLoaderクラスを作成します。アプリでインターフェイスを使用してDllLoaderからDLLを取得し、それをテストしてください。結局、解凍コードの責任はありませんか？

「ファイルシステムの相互作用」がフレームワーク自体で十分にテストされていると想定して、ストリームを操作するメソッドを作成し、これをテストします。FileStream.Openはフレームワークの作成者によって十分にテストされているため、FileStreamを開いてメソッドに渡すことはテストから除外できます。

クラスの相互作用や関数の呼び出しはテストしないでください。代わりに、統合テストを検討する必要があります。ファイルのロード操作ではなく、必要な結果をテストします。

ユニットテストの場合、プロジェクトにテストファイル（EARファイルまたは同等のもの）を含め、ユニットテストで相対パスを使用することをお勧めします（「../testdata/testfile」など）。

プロジェクトが正しくエクスポート/インポートされている限り、単体テストは機能するはずです。

他の人が言ったように、最初は統合テストとしては問題ありません。2つ目は、関数が実際に実行することになっていることだけをテストします。これはすべてユニットテストで実行する必要があります。

示されているように、2番目の例は少し無意味に見えますが、関数がどのステップのエラーに応答するかをテストする機会を与えてくれます。この例ではエラーチェックはありませんが、実際のシステムではそうである可能性があり、依存関係の注入により、エラーに対するすべての応答をテストできます。その後、コストはそれだけの価値があります。