Überprüfen Sie die Abhängigkeit von Anrufen im Komponententest?

Question

Für diese folgende Klasse möchte ich einen Unit-Test schreiben:

public class SomeClass { 

    private Dependency dependency; 

    public SomeClass(Dependency dep){ 
     this.dependency = dep; 
    } 

    private String processString(String s){ 
     /* 
     edit the string and return 
     */ 
    } 

    public void doSomething(String arg){ 

     String processed = processString(arg); 

     dep.doSomethingElse(processed); 
    } 
} 

Zuerst würde ich alle Methoden Stummel SomeClass auf Dependency um ruft meine Klasse in Isolation zu testen. Aber die Frage kann ich noch nicht eine Antwort finden ist:

Soll ich überprüfen, wieSomeClass Anrufe Methoden der Dependency z.B. Welche Parameter werden übergeben? Natürlich ist das ein ziemlich triviales Beispiel, aber ich möchte wissen, ob dies Teil eines Unit-Tests im Allgemeinen sein sollte.

Edit: In meinem Fall Dependency wäre Third Party API-Bibliothek, die ich nicht kontrolliere. Daher würde ich es für wichtig halten, welche Parameter an diese Funktionen übergeben werden, aber ich bin nicht sicher, ob dies Teil eines Komponententests sein sollte.

Answer 1

Ich würde sagen, dass, wenn Abhängigkeit aufgerufen wird, dann sollten Sie mindestens einen Testfall haben, um zu überprüfen, ob es aufgerufen wird. Wenn Sie diesen Fall nicht abdecken wollen, bedeutet das für mich, dass Sie ihn nicht anrufen müssen. Dies ist sehr wichtig, wenn Sie bedingte Anweisungen wie if/else/switch haben. Können Sie sich vorstellen, dass durch Fehler, den Sie gerade

diese Codezeile entfernt

dep.doSomethingElse(processed); 

ohne zu überprüfen, ob die Abhängigkeit aufgerufen wurde Sie noch nicht bemerkt, dass sie entfernt.

Der Test kann wie folgt aussieht:

import static org.fest.assertions.Assertions.assertThat; 

import org.junit.Test; 
import org.junit.runner.RunWith; 
import org.mockito.ArgumentCaptor; 
import org.mockito.Captor; 
import org.mockito.InjectMocks; 
import org.mockito.Mock; 
import org.mockito.Mockito; 
import org.mockito.runners.MockitoJUnitRunner; 

@RunWith(MockitoJUnitRunner.class) 
public class SomeClassTest { 

    @Mock 
    private Dependency dependency; 

    @InjectMocks 
    private SomeClass someClass; 

    @Captor 
    private ArgumentCaptor<String> argumentCaptor; 

    @Test 
    public void shouldCallDependency() throws Exception { 
    //given 
    String arg = "arg"; 

    //when 
    someClass.doSomething(arg); 

    //then 
    Mockito.verify(dependency).doSomethingElse(argumentCaptor.capture()); 
    assertThat(argumentCaptor.getValue()).isEqualTo("processed"); 
    } 

} 

Answer 2

Die Prüfung Dependency sollte nicht Teil Ihrer Komponententests der Klasse SomeClass sein, d. H. Methodenaufrufe von Dependency nicht auf Korrektheit und Genauigkeit prüfen.

können Sie Parameterwert Methoden der Dependency bestanden überprüfen, ob diese Werte in der Klasse lokal sind SomeClass d erstellt und verwaltet von SomeClass ansonsten normale Eingabeprüfung Behauptungen durchführen.

Answer 3

Das ist wirklich hängt von der Situation, und ist sehr meinungsbasierte ...

Ich würde sagen, wenn die Anrufe auf die Abhängigkeit Ihre Methode nur helfen, seine Arbeit zu tun, den Anruf nicht testen. Testen Sie einfach, ob Ihre Methode ihre Aufgabe erfüllt.

Wenn der Aufruf der Abhängigkeit wichtig ist, z. B. wenn der Aufruf der Abhängigkeit ein wichtiger Teil der Funktionalität oder sogar der gesamte Grund für die Ausführung Ihrer Methode ist, sollten Sie prüfen, ob die Abhängigkeit korrekt aufgerufen wird .

Fragen Sie sich: Ist es wirklich wichtig, dass die Abhängigkeit aufgerufen wird und korrekt aufgerufen wird, oder interessiert es Sie nur, dass Ihre Testmethode ihren Zweck erfüllt?

Oder um es aus einer anderen Perspektive zu betrachten: Ist die Abhängigkeit nur ein Teil Ihrer Klasse oder ist es ein unabhängiges Objekt, mit dem Ihre Klasse interagiert?

Ich weiß, das ist eher zweideutig, aber ich hoffe, Sie bekommen die Idee.