What are you testing?

When I first started testing I thought code coverage was the most important statistic. In the past I had written zero tests for my code. Once I learned there was a better way, I went to the opposite extreme. Because of this focus, I attempted to test every line of code.

Imagine a DTO:

public class Foo
{
  public int Bar;
}

Would have a test:

Foo f = new Foo();
f.Bar = 1;
Assert.AreEqual(1,f.Bar);

The problem with this type of testing is that it attempts to test the features of the language. Not only is this unnecessary, but it adds code to the code base, thus increasing the complexity of the project.

Along the same lines:

public class Foo
{
  public Foo()
  {
    Bar = 1;
  }
  public int Bar;
}

Can have the associated test:

Foo f = new Foo();
Assert.AreEqual(1,f.Bar)

Once again, there's no interaction and the test simply tests the features of the language. I picked this example because I saw something similar in a production system. On a side note, I believe the assignment should be done on the declaration line and the constructor should be removed. Then, it is more obvious how unnecessary the test becomes.

Lastly, I have another example from a production system. Class Foo needed to subscribe to an event on Class Bar. If Foo did not subscribe an error would not occur, but invalid results would. Thus, a colleague of mine asked how to test this situation. It turns out that you can mock the add_* method, and therefore test that the subscription occurs. However, I believe this is simply testing that a subscription occurs, not that when the event is raised Foo will handle it correctly. Therefore, a functional test was needed for the business requirement and testing the subscription was unnecessary.

These days, I find myself constantly asking the question "What are you testing". The value in testing is often at interaction points. State based testing adds value, but is usually only necessary after an interaction occurs. As a result much of my tests include mocks.

Code coverage is important and tests can ease maintenece issues; however, having unnecessary tests decreases readibility. Therefore, always know what you are testing.