I’m trying to improve my testing skills. I frequently hear about mocking framework to build fake objects (as far as I understand). Right now I need to test my repository (the usual add, remove, update and GetById methods).
I do this test to be sure that every operation on the database happens correctly.
The question is: Do I really need to mock the repository? For instance, adding a fake repository, I will lose the database engine configuration test part (i.e. using a real repository, rather than a mock, my test will fail even if Entity Framework mapping is incorrect.)
Is this thought right? How should I handle this issue?
2
There are several sides to unit-testing:
- Unit-testing is meant to give you confidence that a component works as it should and that future changes don’t break any of the current functionality.
- Unit tests should be fast enough that you can execute them often without it feeling as a slowdown in your workflow. How fast they should exactly be and how often you should run them is open for debate (and depends to a large extent on the technology you use and your workflow), but you should still aim for them to be fast enough to not be an unwanted interruption.
- Unit tests should be independent of execution order. If all tests pass, you should be able to execute them in all possible permutations of their execution order and still have all of them pass. In particular, no test must depend on being executed after another test.
With that in mind, lets go back to your question about mocking.
When testing the Repository itself, is mocking going to add anything to the points above? Probably not. The Repository is supposed to be the component that communicates with the Database and you want to verify that that happens correctly. And the tests are probably also not so extensive that it is hard to keep them independent and relatively fast.
When testing the rest of your application, it becomes a different story. As databases are generally very good at persisting stuff, also across test cases, and databases are not the fastest components around, the general experience is that testing against a real database makes it an order of magnitude harder to keep all your tests fast and independent.
As the tests of the Repository give you confidence that that component is working correctly, the advise is to stub/mock/fake it in the other tests. In those tests, your fake Repository can control exactly what gets returned and can do it directly from memory.
To round it all off, you also need a couple of end-to-end integration/acceptance tests to verify that the behavior of the stubs/fakes/mocks is consistent with the behavior of the real components.
Testing against a DB is very easy – use transactions and rollback after you’ve performed your operation and checked the result. Alternatively, use a test DB where you populate a set of test data before every test run.
Unit testing doesn’t have to be about isolating every tiny method – Martin Fowler describes a unit as a class plus connected classes when he talks about Agile. So a DB doesn’t have to be a single insert statement against a purely empty DB (and shouldn’t be as you’ll want to check that it works against existing data that breaks constraints)
If you must unit test each method, the easiest way to do this with a DB is to put your SQL into stored procedures. Each procedures is, after all, a solitary method. Then you can test them just like any other method in your business logic classes – inside a transaction, set up some data (truncate, insert), run sproc, check result via a select or other return code, rollback. Easy.