I have recently been looking at some testscripts which looks a bit like...try {  receiveSomething();  // something was received even though it shouldn't  failTest();} catch (TimeoutException e) {  // nothing should be received  succedTest();}The problem I have with these types of tests isThey are not deterministic. You don't know if nothing was sent on purpose or if everything has crashed.Its very hard to simultaneously test something else, which might actually, in this case, send something.My thoughts are one the one side, how can this types of tests be designed better, and secondly can this be an indication of a bigger design smell of the software that is being tested?EDITTo clairify, these test scripts are used for black box-testing of event-based, complex software, not unit testing, and my feeling is that the 'doing nothing' event is a very ambiguous one. :)
Is this a test smell or is it even worse?
code smell;functional testing
From what you wrote, I guess your situation is more like thisstartAsynchronousComplexOperation();try {  receiveSomething(); // listen for events from that async operation above  // something was received even though it shouldn't  failTest();} catch (TimeoutException e) {  // nothing should be received  succedTest();}and the object under test is not receiveSomething, but the asynchronous operation. Thus the outcome of that test depends on the speed of the test machine, if a lot of other processes run on the test machine etc., and this is non-deterministic.IMHO, this is indeed a design problem, and not just a test smell. If your complex operation crashes, or just takes too long, not only your test will give a false negative. Think about how to deal with that situation in production. Is there no requirement to determine for sure that your complex operation is still alive and did not crash? So you may think about adding some kind of watchdog or keep-alive-packet-sending mechanic to your program to get control over that. And once you have such a mechanic available, you can use it in your tests like this:startAsynchronousComplexOperation();while(isComplexOperationStillAlive()){    try {       receiveSomething(); // listen for events from that async operation above       // something was received even though it shouldn't       failTest();   } catch (TimeoutException e) {   }}if(didComplexOperationCrash())    failTest();else    succedTest();