Unit-Test -> Integrationstests

[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!