Writing tests for data access code is hard because we have to find answers to many difficult questions such as:
- What kind of tests should we write?
- How should we configure our tests?
- What should we test?
- How can we write tests that test the right thing, and are both easy to read and maintain?
The thing is that if we make wrong choices, our tests might be useless, hard to read, and “impossible” to maintain.
Unfortunately, I had to learn this in the hard way.
That is why I wrote this tutorial and shared the lessons that I have learned with you. I hope that this tutorial helps you to avoid making the same mistakes.
Introducing: Writing Tests for Data Access Code
This five part tutorial consists of the following blog posts:
- Writing Tests for Data Access Code – Unit Tests Are Waste describes why we shouldn’t write unit tests for our data access code and explains why we should replace unit tests with integration tests.
- Writing Tests for Data Access Code – Green Build Is Not Good Enough describes three rules that we must follow if we want to ensure that our data access code works when it is deployed to the production environment.
- Writing Tests for Data Access Code – Don’t Test the Framework explains why we should write tests only for our own code and helps us to identify the code that we should test.
- Writing Tests for Data Access Code – Don’t Forget the Database describes why we should write deterministic tests that use the real database schema and assert the right thing. This blog post also helps us to achieve these goals.
- Writing Tests for Data Access Code – Data Matters describes the three most common mistakes that we can make when we are using DbUnit datasets and helps us to avoid making them.