Recently we’ve been running into a race condition where a specific error is being thrown from Controller Runtime, however trying to replicate that behavior in a unit test has proven to be quite tricky.
If you think about modifying your code as a set of chain reactions, can you make a change without changing other things? The longer the length of the chain due to a change lets you know that your code is brittle. Tests are no different in this regard.
Now that we’ve covered “why” in the last post, let’s get into what makes a unit test “good”. Good unit tests cover all the code, each test should test one thing and one thing only, and they are completely independent of one another.
Quality tests are key to building quality software. But what makes a quality test? How do I know that the test I’m writing is adequate? Does it cover enough, or am I trying to do too much? What is the benefit of writing tests in the first place? When I started on my journey into the world of automated testing, these were the hardest questions to get a straight answer for.