In the next session(s) we will be focusing on how to make one’s tests database independent. This includes two primary goals:
Designing the code so that all parts of the system can be tested without going to a database. This is important because if it is easy to tailor the data that an object depends upon, it is easy to test behavior. If it is not easy tests suffer—to the point where, being human, developers stop writing tests. Too many projects start out with a good feeling of writing tests only to get bogged down in dealing with setting up the database to control the data the class under test (CUT) depends upon…and then the team drifts into a state of testlessness.
Speeding up the tests. As the tests grow in number, running against the database becomes an issue because the tests get considerably bogged down. A TDD team needs to get around this bottleneck, but a lot of teams struggle with this issue when trying to set out on a course of TDD—and hence never really make it to a disciplined TDD environment.