Unit-Test -> Integrationstests

[Mavarik]

Hallo Zusammen...

Da wir ja alle täglich unsere Klassen per Unittests überprüfen, hat ja sicherlich jeder hierzu eine Idee...

Spaß beiseite...

Oft sind Klassen sehr simpel und einfach zu testen. Was aber wenn die Funktionalität einer Klasse von Faktoren wie Kommunikation oder Timing abhängen, was dann?

Beispiel: Eine http Komponente... Für einen ernsthaften Funktionstest wird ein Http-Server benötigt. (Oder eine Simulation von einem)

Bei einer Kommunikation die immer ein Feedback liefert (ACK) mag das noch zu bewerkstelligen sein, aber was ist mit UPnP bzw. UDP / Broadcast Kommunikation.

Der Sender hat keine Ahnung, ob der Empfänger die Nachricht empfangen hat.

Egal wie wir das Kind nennen : Unittest / Integrationstest / ggf. sogar GUI Test, soll für die Fragestellung keine Rolle spielen.

Bleiben wir mal bei dem Beispiel HTTP... Für einen vollständigen Test benötigt man eine Gegenstelle, also einen Http-Server. Das kann natürlich ein MOCK sein der
einen HTTP-Server simuliert (auch die möglichen Fehler). Aber wer hat schon Lust extra noch einen Server zu programmieren?

Dem Unit-Test also eine 2. Exe mitgeben und im Setup starten / im Teardown killen?

Wie testet Ihr solche Klassen?

Mavarik

[jaenicke]

Das kommt darauf an was alles getestet werden muss.

Bei einem simulierten Server kannst du verschiedene Werte simulieren usw., was du bei einem Test über die normale GUI vermutlich nicht kannst.

Dafür ist es mit TestComplete z.B. sehr einfach beide Seiten zu starten und dann über die Oberfläche zu testen wie ein normaler Bediener die Software bedienen würde.

Beide Varianten werden benutzt. Was man benutzt, hängt davon ab was man genau testen möchte, welchen Aufwand man betreiben möchte, ...

[mjustin]

Warum eine zweite EXE starten? Einfach eine TIdHTTPServer Instanz im Setup erzeugen und im TearDown freigeben.

[Mavarik]

Zitat von mjustin:

Warum eine zweite EXE starten? Einfach eine TIdHTTPServer Instanz im Setup erzeugen und im TearDown freigeben.

Oft geht es um timing - also braucht man mindestens einen 2. Thread... ggf. besonders bei UDP möchte man gerne die Reaktion im Netzwerk haben - da hilft keine lokale Instance...

[mjustin]

Zitat von Mavarik:

Zitat von mjustin:

Warum eine zweite EXE starten? Einfach eine TIdHTTPServer Instanz im Setup erzeugen und im TearDown freigeben.

Oft geht es um timing - also braucht man mindestens einen 2. Thread...

Das ist der Fall - TIdHTTPServer läuft (so wie alle Indy TCP Serverkomponenten) in einem separaten Thread, und erzeugt weitere Threads je Connection.

Ob die TCP Verbindung zwischen Sockets aus zwei verschiedenen Prozessen oder nur innerhalb eines Prozesses stattfinden, macht keinen Unterschied, addressiert wird nur über IP und Portnummer.

[Mavarik]

Zitat von mjustin:

Zitat von Mavarik:

Zitat von mjustin:

Warum eine zweite EXE starten? Einfach eine TIdHTTPServer Instanz im Setup erzeugen und im TearDown freigeben.

Oft geht es um timing - also braucht man mindestens einen 2. Thread...

Das ist der Fall - TIdHTTPServer läuft (so wie alle Indy TCP Serverkomponenten) in einem separaten Thread, und erzeugt weitere Threads je Connection.

Ob die TCP Verbindung zwischen Sockets aus zwei verschiedenen Prozessen oder nur innerhalb eines Prozesses stattfinden, macht keinen Unterschied, addressiert wird nur über IP und Portnummer.

Das ist richtig - Auch wenn es hier nicht die Frage ist - besonders bei UDP spielt es schon eine Rolle ob ich einen 1er Ping oder 300 habe...

Auch die Geschwindigkeit der Gegenseite...

Wenn ich in einer Sekunde 100 UDP Nachrichten sende und die Gegenseite nur 40 verarbeiten/abholen kann - hat man schon ein anderes Ergebnis als lokal...

[Uwe Raabe]

Zitat von Mavarik:

Wenn ich in einer Sekunde 100 UDP Nachrichten sende und die Gegenseite nur 40 verarbeiten/abholen kann - hat man schon ein anderes Ergebnis als lokal...

Sebastian's Hinweis auf TestComplete gilt auch und gerade für diesen Fall. Das TC Framework bietet da einen Haufen Möglichkeiten, die Bedingungen von ideal bis äußerst widrig zu konfigurieren. AUch sind unterschiedliche Last-Szenarien realisierbar. Natürlich kann man das alles auch selbst von Hand mit einem integrierten Server nachbauen (auch SmartBear kann nicht zaubern). Das kostet halt nur eine Menge Zeit und ist längst nicht so flexibel.

[Stevie]

Wenn du genaue und reproduzierbare Ergebnisse willst, dann benutz mocks und implementier das Delay dort.
Dann kannst du einfach testen, wie sich dein Client bei Verzögerungen verhält.

Mittels diverser Patterns sollte das kein Problem darstellen.

[Mavarik]

Zitat von Stevie:

Wenn du genaue und reproduzierbare Ergebnisse willst, dann benutz mocks und implementier das Delay dort.
Dann kannst du einfach testen, wie sich dein Client bei Verzögerungen verhält.

Mittels diverser Patterns sollte das kein Problem darstellen.

Ich denke auch, das ist der beste Weg!