BDD/TDD: Können Abhängigkeiten ein Verhalten sein?

Question

Mir wurde gesagt, ich solle keine Details zur Umsetzung verwenden. Eine Abhängigkeit scheint ein Implementierungsdetail zu sein. Ich könnte es aber auch als Verhalten formulieren.

Beispiel: Eine LinkList hängt von einer Speicher-Engine ab, um ihre Links zu speichern (z.B. LinkStorageInterface). Dem Konstruktor muss eine Instanz eines implementierten LinkStorageInterface übergeben werden, um seine Aufgabe zu erfüllen. Ich kann nicht sagen 'shouldUseLinkStorage'. Aber vielleicht kann ich sagen 'shouldStoreLinksInStorage'.

Was ist in diesem Fall richtig zu "testen"? Soll ich testen, dass die Links in einem Speicher (Verhalten) gespeichert werden, oder soll ich das gar nicht testen?

Answer 1

Die Abhängigkeit selbst ist kein erwartetes Verhalten, aber die Aktionen, die aufgrund der Abhängigkeit aufgerufen werden, sind es sehr wohl. Sie sollten die Dinge testen, die Sie (der Aufrufer) kennen, und vermeiden, die Dinge zu testen, für die Sie intime Kenntnisse über das Innenleben des SUT haben müssen.

Erweitern Sie Ihr Beispiel ein wenig und stellen Sie sich vor, dass unser LinkStorageInterface die folgende Definition hat (Pseudo-Code):

Interface LinkStorageInterface

  void WriteListToPersistentMedium(LinkList list)

End Interface

Da Sie (der Aufrufer) die konkrete Implementierung für diese Schnittstelle bereitstellen, ist es durchaus sinnvoll, dass Sie prüfen, dass WriteListToPersistentMedium() wird aufgerufen, wenn Sie die Save() Methode auf Ihrer LinkList .

Ein Test könnte wie folgt aussehen, wiederum unter Verwendung von Pseudocode:

void ShouldSaveLinkListToPersistentMedium()

  define da = new MockLinkListStorage()  
  define list = new LinkList(da)

  list.Save()

  Assert.Method(da.WriteListToPersistentMedium).WasCalledWith(list)

end method

Sie haben das erwartete Verhalten getestet, ohne implementierungsspezifische Details Ihres SUT oder Ihres Mocks zu testen. Was Sie (meistens) nicht testen wollen, sind Dinge wie:

1. Reihenfolge, in der die Methoden aufgerufen wurden
2. Eine Methode oder eine Eigenschaft öffentlich machen, nur damit man sie überprüfen kann
3. Alles, was nicht direkt mit dem erwarteten Verhalten zu tun hat, das Sie testen

Auch hier ist eine Abhängigkeit etwas, das Sie als Verbraucher der Klasse zur Verfügung stellen, so dass Sie erwarten, dass es verwendet wird. Andernfalls ist es sinnlos, diese Abhängigkeit überhaupt zu haben.

Answer 2

LinkStorageInterface ist kein Implementierungsdetail - sein Name suggeriert eine Schnittstelle zu einer Engine. In diesem Fall ist der Name shouldUseLinkStorage mehr Wert hat als shouldStoreLinksInStorage .

Das sind meine 2 Pfennige wert!