What We Just Learned

When you add asynchronous behavior to a system, you need to make a concerted effort to tame the random effects that it can have on your tests. Build your tests with a knowledge of how the system works and introduce synchronization points where timing issues are likely to arise.

Using sleeps in your steps is not a good way to tackle these timing issues, because it makes your tests slow and doesn’t solve the reliability problem: if the system changes and becomes slower, your sleep may not be long enough and the test will start to break again. The best solution is to listen for events broadcast by the system and pause at the appropriate points in the scenario until those events have been received. That way, you minimize the amount of time the tests waste waiting for the system.

The next best solution is to use sampling to repeatedly poll the system, looking for an expected change of state. This approach works in most circumstances, but you need to take care, especially when the outcome you’re looking for at the end of the scenario looks just the same as at an earlier time in the scenario.

Try This

Do some more experiments with this code, adding sleeps into the code in different places to make sure you understand how the timing issues affect the reliability of the scenario. Try to draw a sequence diagram^[46] of what’s going on as the scenario runs.

Think about your own system. Are there any places where there is asynchronous behavior? How do you work around that in the tests at the moment? Could you improve on that using what you’ve learned in this chapter?