Komponententest: Erforderlich, um Methoden der Klasse selbst zu verspotten?

Question

Ich habe einige Komponententests durchgeführt und mich nur auf das Thema als Ganzes konzentriert.

ich auf das folgende Szenario ab, nehme ich eine Klasse wie dieses:

class A{ 
    public B mehtod_1(B b){ 
    b = method_2(b); 
    b = method_3(b); 
    b += 1; 
    return b; 
    } 

    public B method_2(B b){ 
    // do something to B without external dependency 
    return B; 
    } 

    public B method_3(B b){ 
    // do something else to B without external dependency 
    return B; 
    } 
} 

I-Tests für method_2 und method_3 ohne Probleme schreiben kann, haben verschiedene Tests, die von B auf unterschiedliche Weise zu konfigurieren und die Durchsetzung erwartete Transformation auf B nach dem Aufruf, diese Methoden sind atomar.

Also meine Frage ist:

Wenn ich method_1 in einer atomaren Weise zu testen, würde ich die Anrufe method_2 spotten haben und method_3 da, wenn ich tatsächlich diese Methoden aufrufen, würde ich nicht method_1 in einem Atom testen würde Gutshof.

In letzterem Fall ist method_2 wurde dann gebrochen die Tests für method_1 und method_2 würde brechen, und das wäre irreführend. Wenn ich den method_2 Anruf innerhalb des method_1 Testes verspotten würde, würde nur der method_2 Test ausfallen und eine klarere Anzeige geben, wo der Fehler ist (nämlich irgendwo in der Geschäftslogik von method_1 gegeben alle anderen aufgerufenen Methoden funktionierten wie erwartet).

Habe ich das Konzept hier richtig verstanden?

Auf der anderen Seite ist es richtig, wenn beide Tests fehlschlagen, da in der realen Welt method_1 nicht funktionieren kann ohne method_2 funktioniert.

würde Mein Bauch sagt Unteilbarkeit der Tests ist es, was gewünscht wird, die erste Lösung bedeutet, wo es ein Test für method_1 ist, für jedes mögliche Ergebnis method_2 und method_3 (statisch verspottet).

Gibt es einen "richtigen"/gemeinsamen/Best Practice Weg?

Answer 1

Sofortige Antwort: falls wir Java hier sprechen; und teilweise Mocking ist wirklich von Interesse für Sie, können Sie in Mockitos Verwendung spy Konzept suchen.

Aber darüber hinaus: Sie bekommen Unit-Tests falsch. Was Sie anrufen Atomarität; Ich rufe an, der über Implementierungsdetails sich sorgt. Aber es sollte nicht wichtig sein, "was genau" diese "Methode im Test" tatsächlich tut. Sie möchten die was, nicht die wie testen.

Bedeutung: Wenn diese Methode eine andere Methode (s) aufrufen muss (das funktioniert gut in Ihrer Testumgebung; ohne zu spotten); dann muss man nicht darüber nachdenken, sie zu verspotten!

Sie sehen: Sie kümmern sich um die Vertrag von jeder Ihrer Methoden. Dieser Vertrag ist, was Sie testen möchten: gegeben diese Eingabeparameter, ich erwarten das Ergebnis/Nebeneffekt/Ausnahme ...

Dennoch, die Tatsache, dass Sie mehrere öffentliche Methoden haben; und dass sie irgendwie voneinander abhängig sind könnte ein Hinweis auf ein Designproblem sein (wie in: macht es Sinn, dass sie alle öffentlich sind? Gibt es Abstraktionen, die sich in deiner Schnittstelle verstecken, die du besser anders ausdrücken solltest?) . Aber das kann nur mit echtem Code entschieden werden; echter Kontext.