In a lot of projects I have been on I’ve seen the following approaches when it comes to application logging in test:

1. The most popular option: It is completely ignored, either by pumping it into a mock or a NullLogger
2. It is tested by verifying that the correct log messages are written. This is usually done to satisfy a ‘strict’ mocking framework.

Neither of these options are ideal in my opinion. The first option totally hides the logging, making it hard to see if it is actually valuable. The second option adds too much noise into the tests, since verifying that the message is written doesn’t tell me much.

Recently I wanted to verify that my data access layer could properly read and write to a SQL Server database, and I wanted to have these tests automated. I wanted to answer these questions:

1. Can my DbContext roundtrip entities to the database and back?
2. Does the schema in my migration scripts match the expected schema in my code? (follows from 1)
3. Can my migration scripts be applied to the database correctly?

Since I was using SQL Server I could utilize SQL Server LocalDB that comes with Visual Studio. To keep performance acceptable I do not want to create and destroy a database for each test, so I need a way to reset the database after a test has run.