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 actually a bit misleading, because often we end up verifying that the correct […] Read more
Unit Testing
When we write tests for our data access code, we must follow these three rules: Our tests must use the real database schema. Our tests must be deterministic. Our tests must assert the right thing. These rules are obvious. That is why it is surprising that some developers break them (I have broken them too […] Read more
When we write tests for our data access code, should we test every method of its public API? It sounds natural at first. After all, if we don't test everything, how can we know that our code works as expected? That question provides us an important clue: Our code. We should write tests only to […] Read more
The first thing that we have to do before we can start writing integration tests for our data access code is to decide how we will configure our test cases. We have two options: the right one and wrong one. Unfortunately many developers make the wrong choice. How can we avoid making the same mistake? […] Read more
A few years ago I was one of those developers who write unit tests for my data access code. I was testing everything in isolation, and I was pretty pleased with myself. I honestly thought that I was doing a good job. Oh boy was I wrong! This blog post describes why we shouldn’t write […] Read more
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 blog post describes how we can identify the logical […] Read more