A Philosophy of Testing 6: The Quest for Determinism

Determinism is Your Friend

The way you avoid this is by making your tests, and the code itself, as deterministic as possible. That flakiness is usually the result of some sort of non-determinism — or to put it more plainly, randomness.

Time Management

One of the easiest things to control is too often overlooked: your clock.

Don’t Wait for Non-Events

One more aspect of this: sometimes, you need to be testing for nothingness. That is, you send an event to your controller entry point, and you specifically want to check that, in this use case, nothing observable happens. For example, you might be receiving an incoming stream that calls an external API every tenth message, when a buffer fills up. Testing that it calls after ten messages is easy; testing that it does not call on the ninth is trickier.

Test Your Race Conditions

Finally, one of the most pernicious sources of bugs is race conditions in your code. Obviously, you should avoid those being possible whenever you can. But what if you can’t?

Conclusion

Note the implication of much of the above: you need to write your code specifically to make it testable. I’ll have a lot more to say about that in the next installment, including some recommendations about a useful TestHooks approach that I often use.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mark "Justin" Waks

Mark "Justin" Waks

Lifelong programmer and software architect, specializing in online social tools and (nowadays) Scala. Architect of Querki (“leading the small data revolution”).