Unit-Test-Code mit einer Dateisystemabhängigkeit

Es gibt wirklich nichts falsch mit diesem, es ist nur eine Frage, ob Sie nennen es einen Komponententest oder Integrationstest. Sie müssen nur sicherstellen, dass wenn Sie in Interaktion mit dem Dateisystem, es gibt keine unerwünschten Nebenwirkungen. Stellen Sie insbesondere sicher, dass Sie bereinigen nach sich selbst -- löschen Sie alle temporären Dateien, die Sie erstellt haben-und dass Sie nicht versehentlich überschreiben einer vorhandenen Datei, die zufällig den gleichen Namen wie eine temporäre Datei, die Sie verwenden. Verwenden Sie immer relative Pfade und nicht absolute Pfade.

Wäre es auch eine gute Idee, um chdir() in ein temporäres Verzeichnis, bevor Sie Ihren test, und chdir() Rücken hinterher.

InformationsquelleAutor der Antwort Adam Rosenfield

Ihre Frage stellt eine der schwierigsten Teile der Prüfung für die Entwickler nur immer hinein:

"Was zur Hölle soll ich testen?"

Dein Beispiel ist nicht sehr interessant, weil es einfach nur klebt einige API-Aufrufe zusammen, so, wenn Sie waren, um Schreibe einen unit test für Sie, die Sie würde am Ende nur behauptet, dass die Methoden aufgerufen wurden. Tests wie diese eng paar Ihrer Umsetzung im Detail zu testen. Das ist schlecht, denn jetzt müssen Sie zum ändern des test-jeder Zeit ändern Sie die details der Implementierung der Methode, weil die änderung die details der Implementierung bricht Ihre Prüfung(en)!

Mit schlechten tests ist tatsächlich schlimmer, als wenn Sie keine tests in allen.

In deinem Beispiel:

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

Während die Sie übergeben können, mocks, es gibt keine Logik in der Methode zu testen. Wenn Sie versuchen, einen unit-test für diese könnte es in etwa so Aussehen:

//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);
}

Herzlichen Glückwunsch, Sie im Grunde kopieren-einfügen die details der Implementierung Ihrer DoIt() Methode in einem test. Gerne pflegen.

Wenn Sie tests schreiben, Sie möchten testen Sie die WAS und nicht die WIE.
Sehen Black-Box-Tests für mehr.

Den WAS ist der name der Methode (oder sollte es zumindest sein). Die WIE sind all die kleinen details zur Implementierung, die Leben in Ihrer Methode. Gute tests erlauben, Sie zu tauschen die WIEohne die WAS.

Denken Sie an es auf diese Weise, Fragen Sie sich:

"Wenn ich die details der Implementierung dieser Methode (ohne Veränderung des öffentlichen Auftrags) wird es brechen mein test(s)?"

Wenn die Antwort ja ist, werden Sie die Prüfung der WIE und nicht die WAS.

Zur Beantwortung Ihrer konkreten Frage über das testen von code mit Datei-system-Abhängigkeiten, lassen Sie uns sagen, Sie hätten etwas Interessantes passiert mit einer Datei, und Sie wollte speichern Sie die Base64-codierten Inhalt einer byte[] zu einer Datei. Sie können streams für dieses zu testen, ob der code das richtige tut, ohne vorher zu prüfen wie er es tut. Ein Beispiel könnte so etwas wie dies (in 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");
}

Der test verwendet eine ByteArrayOutputStream aber in der Anwendung (Verwendung von dependency injection) die Reale StreamFactory (vielleicht namens FileStreamFactory) zurückkehren würde FileOutputStream aus outputStream() - und schreiben würde, ein File.

Was war interessant über die write Methode ist hier, dass es war das schreiben, die Inhalte aus Base64-codiert ist, so das ist, was wir getestet. Für Ihre DoIt() Methode, dies wäre mehr angemessen getestet mit einem Integrationstest.

InformationsquelleAutor der Antwort Christopher Perry

Es ist nichts falsch mit dem schlagen der Datei-system, nur halten es für eine integration-test eher als eine Einheit zu testen. Ich würde die swap-hart codierten Pfad durch einen relativen Pfad, und erstellen Sie eine Testdaten-Unterordner enthalten, die Reißverschlüsse für die unit-tests.

Wenn Ihr Integrations-tests zu lange laufen, dann trennen Sie diese heraus, damit Sie nicht so oft wie Ihre schnelle unit-tests.

Stimme ich zu, manchmal denke ich, interaction-based testing kann dazu führen, zu viel Kupplung und endet oft nicht genügend Wert. Sie wirklich wollen, um zu testen, entpacken Sie die Datei hier nicht nur überprüfen, dass Sie den Aufruf der passenden Methoden.

InformationsquelleAutor der Antwort JC.

Scheint dies eher ein integration-test, wie Sie abhängig sind von einem bestimmten detail (das Dateisystem), die sich ändern könnte, in der Theorie.

Ich würde abstrakter der code, der sich mit den OS in es ist ein eigenes Modul (Klasse, Montage, Glas, was auch immer). In Ihrem Fall, die Sie laden möchten eine bestimmte DLL, wenn gefunden, so stellen Sie eine IDllLoader-Schnittstelle und DllLoader Klasse. Haben Sie Ihre app erwerben, die DLL aus der DllLoader mit dem interface und test, .. du bist nicht verantwortlich für das entpacken code doch Recht?

InformationsquelleAutor der Antwort tap

Sollten Sie keine test-Klasse zusammenspiel und die Funktion aufrufen. stattdessen sollten Sie überlegen, integration-Tests. Test das gewünschte Ergebnis und nicht die Datei laden Betrieb.

InformationsquelleAutor der Antwort Dror Helper

Wie schon andere gesagt haben, die erste ist gut als ein integration-test. Die zweiten tests nur das, was die Funktion soll, um tatsächlich tun, das ist alles eine unit-test tun sollten.

Wie gezeigt, im zweiten Beispiel sieht ein wenig sinnlos, aber es gibt Ihnen die Möglichkeit, zu testen, wie die Funktion reagiert auf Fehler in einem der Schritte. Sie haben noch keine Fehlerprüfung im Beispiel, aber im realen system Sie haben können, und das dependency injection-würde Sie test alle Antworten auf etwaige Fehler. Dann werden die Kosten sich gelohnt haben wird.

InformationsquelleAutor der Antwort David Sykes