[zeromq-dev] How should test cases be written?

Goswin von Brederlow goswin-v-b at web.de
Sat Jan 18 14:19:27 CET 2014


having written a patch for connection notification on STREAM sockets I
wonder about the test case for stream sockets.

Currently there are 3 tests with STREAM sockets (tested in that order):

1) test_stream: (uses recv/send)
   + test connecting a STREAM and DEALER socket
   + test connecting a STREAM and STREAM socket

   Tests connection notification, sending messages, closing sockets
   and disconnect notification all in one.

2) test_stream_disconnect_notifications:  (uses recv/send_msg)
   + test connecting a STREAM and STREAM socket with polling

3) test_stream_empty: (uses recv/send_msg)
   connecting a STREAM and DEALER socket
   + testing zmq_msg_close on an empty message?

As it is test_stream will fail if anything is wrong with STREAM
sockets regardless of what it is.

I wonder: Is the line number of the failure enough of a clue what is
wrong? Or should there be more tests that test things step by step?

Esspecially test_stream contains 2 completly seperate tests:
STREAM/DEALER and STREAM/STREAM. Shouldn't that at least be split?

Secondly I wonder if the tests should care about blocking. They don't
set a timeout on the sockets, don't use non-blocking calls and most
don't set LINGER to 0 before closing sockets and destroying the
context. So if anything goes wrong, like the connect notification not
being send, the test simply hangs. It doesn't fail. Shouldn't they?

So what is the rule for this in the zmq project?


More information about the zeromq-dev mailing list