We have learned that “clean” unit tests might not be as clean as we think. We have done our best to make our unit tests as clean as possible. Our tests are formatted properly, use domain-specific language, and avoid excessive mocking.

If our code has obvious faults, we are very motivated to improve it. However, at some point we decide that our code is “good enough” and move on. Typically this happens when we think that the benefits of improving our existing code are

When we write unit tests that use mock objects, we follow these steps: Configure the behavior of our mock objects. Invoke the tested method. Verify that the correct methods of our mock objects were invoked. The description of the third step is

A good unit test should fail for only one reason. This means that a proper unit test tests only one logical concept. If we want to write clean tests, we have to identify those logical concepts, and write only one test case per logical concept. This

Automated tests are worthless if they don’t assert anything, but the problem of regular JUnit assertions is that they speak the wrong language and become messy if we have to write a lot of them. If we want to write tests which are both easy