Unit: A multithreaded unit reads data of a queue and processes it, sending it off to another queue. When the last item is processed (null value found) the process stops.

Test: Place a set of known data in the queue and run. Check that data placed on the output queue is correct.

If the unit is incorrectly programmed, it may continue trying to read and process nulls of the queue. This may or may not result in an exception (using Java as the example language). So this test could conceivably cause an infinite loop.

Should the test keep track of the number of items read off the queue and throw an error if more than the specified number of elements is read? or should the test continue to run, knowing that the runner(human) will see that it is not ending?

  • Isn't this yet another question which really belongs on SO? Dec 2, 2010 at 20:07
  • 1
    I don't think so, because I don't think there is a clear right answer, and it's not language-specific. I hope there is a best one, though.
    – Michael K
    Dec 2, 2010 at 20:09

3 Answers 3


Tests should always terminate (ideally quickly!).

If you have a test that doesn't terminate, your continuous integration server will fail its test run, which is great, but the failure will likely be "your test suite took too long so I killed it", which isn't very helpful.

In this case, if you have N items in the list and you've read N + 2 items already, then your test should fail, and explain why (say, a message like "test failed because it was about to loop infinitely").

  • +1 because it's the ideal approach (you'd probably have a mock implementation of the queue which kept track of the number of items popped and threw an exception when too many were attempted)
    – Gary
    Dec 6, 2010 at 20:27

I agree with Frank: unit tests should run quickly to give fast feedback. An infinite loop won't give you fast feedback!

Further, our unit test framework has a (configurable) 30 second timeout. Exceed this and the test is terminated and it fails and it moves onto the next.


The test in this case is "For_Given_Input_Output_Is_As_Predicted". The moment the output will never match the prediction (i.e. it exceeds the number of items inserted), you can reliably treat the test as failed. So that is what you should do.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.