I am looking at writing some integration tests that will ensure my messaging layers behaves correctly upon lost packets/network issues as I need to be sure there will be no duplicates when a process reconnects either end of the connection, ideally not keeping a list of received messages.
TCP is used a the Connection Protocol
Test Scenarios I want to test are:
- Sender Cannot connect (easy enough to test by connecting to non existent server)
- Server receives but something happens in between TCP and Application Layer on Client when receiving confirmation, after the TCP ACK. E.g. server thinks its ACK'ed, client never receives it. (is this a viable worry in any application?)
I am currently thinking of implementing a new process that will act as a proxy for TCP connection, and connect to it via WCF from the integration test to configure the forwarding initially and then switch it on/off, or decide which packets get forwarded and which don't via a callback in the test. Therefore can simulate a scenario like that.
- Is there something like that already in C#?
- Has someone tried this already and failed? Why?
- Is there a better approach (especially for message based testing)?
Thanks
Aucun commentaire:
Enregistrer un commentaire