I’m a big fan of unit tests. But not everything can and should be unit tested. Also I do love CQRS architecture – it provides awesome separation of read and writes and isolates each read from the next read via query classes. Usually my queries are reading data from a database, though they can use any persistence i.e. files. About 90% of my queries are run against database with Entity Framework or with some micro ORM (currently I’m a fan of PetaPoco, though Dapper is also grand).

And no amount of stubs/mocks or isolating frameworks will help you with testing your database-access layer without actual database. To test your database-related code you need to have a database. Full stop, don’t even argue about this. If you say you can do unit-tests for your db-layer, I say your tests are worth nothing.

A while ago I’ve blogged about integration tests and that article seems to be quite popular – in top 10 by visitors in the last 2 years. So I decided to write an update.

Continue reading

One of the questions I have to answer frequently (mostly question myself) is “why should I write unit tests?”. One of the simplest answers it “They help you discover bugs”.

When you are writing unit test, you should not think about the internals of your methods, but rather about results you would like to get from that method. Kind of black-box testing. If you are not doing TDD, it also can help if you write tests the next day, when implementation details of your methods are not so fresh in your head.

Today I discovered yet another problem in the implementation of RavenDBMembershipProvider: most of the code is not mine there, but I’m writing tests and aim close to 100% coverage. Now in the main class only a few lines of code are not covered. When I started writing last few tests for these lines, I have discovered a problem. Without tests that would possibly be never discovered.. and possibly could lead to a security vulnerability.