Question

I’m looking at unit tests for the first time.
As I’m in Visual Studio 2008 I started with the build in testing framework.

I’ve hit the button and started looking at filling in the blanks, it all seems fairly simple.

Except, I can see two problems.

1) A lot of the blank unit tests seem to be redundant, is there a rule of thumb for choosing which methods not to write unit tests for.
2) Is there a best practise for writing tests for methods that read/write a database (SQL Server in this case)

I’ll give an example for (1).

I’m writing unit tests for a WCF web service. We use wscf.blue to write our web service WSDL/XSD first.

Here’s the path through the (heavily simplified) code for the methods which consumes a list of Users and writes them to the Users table in the database.

Entry Point
   |
   |
   V
void PutOperators(PutOperatorsRequest request) (This method is auto generated code)
   |
   |
   V
void PutOperatorsImplementation(PutOperatorsRequest input) (Creates a data context and a transaction, top level exception handling)
   |
   |
   V
void PutEntities<T>(IEnumerable<T> input) (Generic method for putting a set of entities into the database, just a for loop, T is Operator in this case)
   |
   |
   V
U PutEntity<T, U>(T entity) (Generic Method for converting the input to what the database expects and adding it to the DataContext ready for submission, T is Operator, U is the data layer entity, called User)
   |
   |
   V
(This method calls 3 methods, first 2 of which are methods belonging to "entity" passed into this method, the 3rd is an abstract method that, when overridden,  knows how to consume a BL entity and flatten it to a database row)
void EnsureIDPresent() (Ensures that incoming entity has a unique ID, or creates one)
void ValidateForInsert(AllOperators) (Does this ID already exists, etc)
User ToDataEntity(Operator entity) (simple field mapping excersice, User.Name = Operator.Name, etc)

So, as far as I can tell I have 3 methods that do something obviously testable:

EnsureIDPresent() – This method takes and input and modifies it in an easily testable way
ValidateForInsert() – This method takes the input and throws exceptions if criteria are not met
ToDataEntity() – This method takes an input, creates a data row entity and populates the values. Should be very easy to test.

There is also:

PutOperatorsImplementation() – It’s here that DataContext.SubmitChanges() and TransactionScope.Complete() is called. Should I write tests to test what is written to the database? And then what? Delete them the records? Not sure what to do here.

I think I should delete the tests for:

PutOperators() – Auto generated code, one line, calls PutOperatorsImplementation()
PutEntities()– Just a for loop calling PutEntity(), and it’s a generic method on a base class
PutEntity() – Calls three methods that already have unit tests and the calls DataContext.InsertOnSubmit.

I have a similar path for getting the data as well:

GetOperatorsResponse GetOperators(GetOperatorsRequest request) – Auto generated

GetOperatorsResponse GetOperatorsImplementation(GetOperatorsRequest input) – Set up DataContext

List<Operator> GetEntities() – Linq Query

Operator ToOperator(User) – Flattens one data entity into it’s equivalent BL entity.

I think I should just be testing ToOperator() and GetEntities()

Should I just have a dedicated test database with known good test data in it?

Is that the correct way to approach this?

Answer 1

There is no “hard and fast” rule as to what you should and should not test.

Unit tests are there to Test any implementation your’e writing works and to enable you to be confident when re-factoring that you haven’t broke anything. You need to consider whether the tests you write will give you value or not.

The main things you need to consider when deciding what code to cover are

• How likely is the code I’m about to write / have written likely to
  change and need refactoring?
• Is the code written mainly custom code or autogenrated – If
  autogenrated then there is little value in writing tests as your
  simply just testing the autogenerator you are using does its job
  properly (and you should be able to trust it).

You should not use databases or anything that can change outside of the test environment to test Data access code. Instead consider writing “Mocks” to mock the response from the data layer for your tests. This will ensure your tests are consistent. Consider looking at some mocking frameworks such as Rhino Mocks Or MOQ.

Always remember you are writing test for a reason and not for the sake of writing test. If you are not going to gain any value from the tests you write(e.g. if your codebase is not going to change) then simply don’t write them.