Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Isn't this yet another question which really belongs on SO? – Bjarke Freund-Hansen Dec 2 '10 at 20:07
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 '10 at 20:09
up vote 10 down vote accepted

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").

share|improve this answer
+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 Rowe Dec 6 '10 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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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