Perfect Test Coverage

When SC got hired, the manager said “unit testing is very important to us, and we have 100% test coverage.”

Well, that didn’t sound terrible, and SC was excited to see what kind of practices they used to keep them at that high coverage.

[Test]
public void a_definition() {   

Assert.True(new TypeExpectations<IndexViewModel>()
                            .DerivesFrom<object>()
                            .IsConcreteClass()
                            .IsSealed()
                            .HasDefaultConstructor()
                            .IsNotDecorated()
                            .Implements<IEntity>()
                            .Result);
}

This is an example of what all of their tests look like. There are almost no tests of functionality, and instead just long piles of these kinds of type assertions. Which, having type assertions isn’t a bad idea, most of these would be caught by the compiler:

• DerviesFrom<object> is a tautology (perhaps this test framework is ensuring it doesn’t derive from other classes? but object is the parent of all classes)
• IsConcreteClass would be caught at compile time anywhere someone created an instance
• HasDefaultConstructor would again, be caught if it were used
• Implement<IEntity> would also be caught anywhere you actually tried to use polymorphism.

IsSealed and IsNotDecorated will actually do something, I suppose, though I wonder how much I actually care about that something. It’s not wrong to check, but in the absence of actual real unit tests, why do I care?

Because every class had a test like this, and because of the way the test framework worked, when they ran code coverage metrics, they got a 100% score. It wasn’t testing any of the code, mind you, but hey, the tests touched all of it.