Unit Testing .... ein Datenanbieter?

Question

Gegebenes Problem:

• Ich mag Komponententests.
• Ich entwickle Connectivity-Software zu externen Systemen, die ziemlich oft und oft eine C++ - Bibliothek verwenden
• Die Rückkehr dieses Systems ist nicht-deterministisch. Daten werden während des Laufens empfangen, aber es ist schwierig, sicherzustellen, dass alles korrekt interpretiert wird.

Wie kann ich das richtig testen?

Ich kann einen Komponententest ausführen, der eine Verbindung herstellt. Leider wird es dann einen Leben Datenstrom verarbeiten. Ich kann sagen, ich führe den Test für 30 oder 60 Sekunden vor dem Trennen, aber Code coverage ist unmöglich - ich nicht einfach closeclose, um alle Code Pfade immer nur einmal pro Tag (Fehlercode Pfade werden selten ausgeführt). Ich kann auch nicht jedes Ergebnis wirklich behaupten. Abhängig von der Tageszeit sprechen wir von 20 000 Datenrückrufen pro Sekunde - die alle nicht ausreichend gut genug sind, um jeden von ihnen auf Konsistenz zu überprüfen. Spott? Nun, das würde mich eine leere Hülle von mir testen lassen, da der Code, der die Ereignisse behandelt, im Grunde der zu testende Fall ist. In vielen Fällen sprechen wir hier von einer KOMPLEXEN c-Level-Struktur - schwer zu spottende Frameworks, die von Csharp zu integrieren C++

Wer eine Idee? Ich gebe den Unit-Test für diesen Teil der Anwendung nicht auf.

Answer 1

Komponententests sind gut, aber es sollte nicht Ihre einzige Waffe gegen Bugs sein. Schauen Sie in the difference between unit tests and integration tests: es klingt für mich wie Letzter ist Ihre beste Wahl.

Auch automatisierte Tests (Komponententests und Integrationstests) sind nur sinnvoll, wenn sich das Verhalten Ihres Systems nicht ändert. Wenn Sie die Rückwärtskompatibilität mit jeder Version umgehen, werden Ihnen die automatisierten Tests dieser Funktionalität nicht weiterhelfen. Sie können auch eine vorherige Diskussion auf how much unit testing is too much sehen.

Answer 2

Implementiert Ihre externe Datenquelle eine Schnittstelle - oder können Sie mithilfe einer Kombination aus einer Schnittstelle und einem Wrapper um die Datenquelle, die die Schnittstelle implementiert, die zu testende Klasse von der Datenquelle entkoppeln. Wenn einer der beiden Werte zutrifft, können Sie die Datenquelle in Ihren Komponententests überspionieren und die Daten aus der Scheininstanz bereitstellen.

public interface IDataSource 
{ 
    public List<DataObject> All(); 
    ... 
} 

public class DataWrapper : IDataSource 
{ 
    public DataWrapper(RealDataSource source) 
    { 
     this.Source = source; 
    } 

    public RealDataSource Source { get; set; } 

    public List<DataObject> All() 
    { 
      return this.Source.All(); 
    } 
} 

nun in der Klasse unter Test ist abhängig von der Schnittstelle und eine Instanz injiziert, dann in den Komponententests, eine Mock-Instanz zur Verfügung stellen, die die Schnittstelle implementiert.

public void DataSourceAllTest() 
{ 
    var dataSource = MockRepository.GenerateMock<IDataSource>(); 
    dataSource.Expect(s => s.All()).Return(... mock data ...); 

    var target = new ClassUnderTest(dataSource); 

    var actual = target.Foo(); 

    // assert something about actual 

    dataSource.VerifyAllExpectations(); 
}