Isolating the Database When Testing

Jimmy Bogard wrote a post about Isolating the database when testing. I highly recommend reading it.

I’d like to add another option.

When writing tests, each test is responsible for it’s own data. This means if the test needs a user, it will create it’s own user and any supporting data. At times this can be challenging, especially as the schema changes. To help mitigate this issue, we use classes to encapsulate the data creation. When the schema does changes it’s a simple to change the tests in a centralized location. In most cases there is zero impact on the logic of the tests.

The second part of this is, data is not deleted. This is very important. Data grows and illuminates potential performance issues. As time passes, you’ll start seeing area’s of the application slowing down. These are performance smells. It may be an index is needed. It could be a synchronous process that should be an asynchronous process. Many of these performance issues to do not expose themselves until you’ve been in production for a number of weeks. Even load testing may not catch these issues. At that point it’s too late.