In the first post in this series, I presented several reasons to not us a database pre-populated with data for unit testing. The second post, presented an alternative approach to using a pre-populated database. This post will address the common concerns with the approach.
Concern: If we fake the table, we’re not testing the real thing. The reality: “Not testing the real thing” is a common argument against any mock framework. Remember, we’re talking about unit testing – pinpointing a small, specific piece of functionality to exercise. Other forms of testing will cover the entire system as it is integrated together. By focusing on small units, you can achieve higher test coverage. You will also establish a safety-net for refactoring.
Concern: Constraints need to be tested too. The reality: I completely agree. While unit testing, you can write test cases against the constraints. After faking a table, you can re-apply the constraints which you’d like to test. This actually improves your ability to test the constraints, as you can do so in isolation of other functionality.
Concern: We need realistic data that we got from the customer. The reality: There are times and places to use such data if you have it. Unit testing is not it. This type of data is better utilized during integration, usability, and performance testing. Using customer data during unit testing will prevent you from thinking about scenarios which don’t occur now in the data, but may occur later. Defects will hide among those untested scenarios.
As you become experienced with this approach to unit testing, you will also find the following benefits:
- Code is less coupled.
- It is easier to test date and time based scenarios.
- Your tests are not slowed down by having a large amount of data in the database.
- It is easier to version control everything needed for unit testing.
- You’ll prevent more defects before integrating the code.