Is this typical unit testing experience?

Question

I've written a 220 line class with 5 public methods. I have a unit testing class that runs 28 tests on this class which takes up over 1200 lines of code, but this is mostly due to repeated code used in setting the tests up. This code is testing the DAL in my project to ensure it interacts with the database correctly and that the stored procedures involved are running correctly. It seems like I have done a lot of work to test very little code. I am using mocks with Rhino mocks to avoid writing my own stubs where possible.

Is this typical unit testing experience?

Answer 1

In what way typical?

If you mean you have more unit test code than actual code, then yes. But you should treat your unit test code the same way as your 'real' code in that you should remove duplication and refactor it until it's as lean as possible/desirable.

Also if you're testing the DAL and the interaction with a real database then what you have there is an integration test.

EDIT

I've recently taken to writing unit test base classes for common testing patterns, I have a lot of setup code and helper methods in there. My most recent unit test base class is a generic one which allows me to test wcf-web-api classes very easily. So, my actual test classes are very lean and 'to the point'. YMMV

Answer 2

It is fairly common that unit test classes contain more LOC than actual tested classes. That's reasonable considering setting up dependencies, preparing faked data and all the unit testing related fuss.

However, testing DAL in terms of interacting with database and checking if correct procedures are invoked smells like an integration test. You might want to rethink what you want to do. With unit testing, all the DB-talking should be mocked/stubbed.

If you're having issues with 1200 lines of code, you can break up your tests into contexts, eg. every context matching particular part of tested class (public method, set of properties and so on).

Edit:

Just to add example that other's do that aswell. You can check sources of Aggregate and AggregateTests classes from Edulinq project. 15 tests to test 3 public methods, with tests class being twice as big as tested one.

Answer 3

Yes this is quite normal for unit testing.

The size of the code required to run tests is often underestimated, particularly code that requires a lot of set up boilerplate, such as database access.

While you could try to refactor the set up code into separate methods, this is quite normal for the situation you are describing.

With 28 tests, your 1200 lines reduces to about 43 per test. Considering you are repeating your setup code this is quite reasonable.

Answer 4

28 tests for one class sounds like the class is doing too many things.