Toward the beginning there is quite a nice illustration of why you might not find Heisenbugs by stress testing. Further in there is a more detailed explanation of how CHESS works, and how the thread interleaving state space is reduced to a manageable level.

In this installment we see how to use the managed version of CHESS within a Visual Studio concurrency unit test.

Finally, here we get an overview of the tooling which helps visualise different thread interleavings.

The answer is not much. It’s easy to spot which code you didn’t execute. For code that did execute, if neither the behaviour nor resultant state is verified, all you really know is that there were no unexpected errors. In other words, this code coverage is merely incidental, and no actual testing took place.

Furthermore, even with 100% coverage you have no indication of the code you should have written, but didn’t. For example, consider this simple one liner:

public float Divide(float dividend, float divisor)
{
   return dividend / divisor;
}
 
public void TestDivide()
{
   float quotient = Divide(10, 2);
   Assert.AreEqual<float>(5, quotient);
}

The test case gives us 100% block coverage. However, we will get different behaviour if we use a divisor of 0. This different behaviour may very well constitute a bug. Interestingly, we won’t find this bug even if we use a more robust coverage metric (e.g path coverage) because it is a boundary problem.

public class NiceClass
{
    private DependentClass injectedDependency;
 
    public NiceClass(DependentClass injectedDependency)
    {
        this.injectedDependency = injectedDependency;
    }
 
    public void CoupledMethod()
    {
        using (IFace c = new Face(injectedDependency))
        {
            // do something with c
        }
    }
}

We can see that injectedDependency is not coupled, but what about the local instance of Face in CoupledMethod? To decouple it use a delegate to return the IFace instance instead of calling new directly. If the coupling had been to a concrete type (Face), we could refactor to an abstract type (IFace) or wrapper first.

public class NiceClass
{
    public delegate IFace IFaceCreatorDelegate(DependentClass injectedDependency);
 
    private DependentClass injectedDependency;
    private IFaceCreatorDelegate iFaceCreator;
 
    public NiceClass(DependentClass injectedDependency, IFaceCreatorDelegate iFaceCreator)
    {
        this.injectedDependency = injectedDependency;
        this.iFaceCreator = iFaceCreator;
    }
 
    public void CoupledMethod()
    {
        using (IFace c = iFaceCreator(injectedDependency))
        {
            // do something with c
        }
    }
}

This is an additional three lines of code, which arguably makes the control flow harder to read statically. It does, however, improve testability. I think of this as equivalent to the classic tradeoff between abstract and concrete parameters.

Instantiating NiceClass is not too arduous either with a lambda expression (although it is still a little verbose).

NiceClass nice = new NiceClass(
   dependency, 
   (DependentClass d) => new Face(d));

Microsoft research have published a paper exploring the effect of TDD on various quality metrics. You can check out a short Channel 9 overview here.