Test-driven development in a challenging environment

I started writing my master’s thesis today. It will be a case study on a project where I will re-implement part of an existing system using test driven development. What makes it interesting is that the component to be implemented consists of a SharePoint Web Part user interface and it integrates to Microsoft Project Server. I haven’t done any .Net or SharePoint development in ages and the guys at work said that it’s quite difficult to write unit tests for that kind of stuff. Of course I didn’t believe them!

I think I’ll be making notes on interesting findings here if there will be any.

Code coverage

Full test coverage is a good goal to reach for but it does not prove your program correct.

public int multiply(int a, int b) {
  return a + b;
}

public void testMultiply() {
  assertEquals( 4, multiply(2,2) );
}

The above multiply method has full test coverage (statement, path) and it passes the test(s) but it clearly doesn’t do what it is supposed to do.

Generating code documentation form unit tests

I have been practicing test-driven development for a year now. I like it. There is one problem though I’d like to solve. It has been said that unit tests document what the code does and how to use it. In most projects that I have been involved in, this not a very accurate description. The unit tests are normally not very well structured and the names of the unit tests do not describe very well what the code should do. This is likely due to not refactoring the tests as often as the code.

Here is a fragment from a hypothetical unit test:

public class UnitTestingPracticeTest extends TestCase {

  public void testUnitTestDescribesWhatTheCodeDoes() {

    assertNotNull(unitTest.getDescription());

  }

  public void testUnitTestDescribesHowToUseTheCode() {

    UnitTest unitTest = new UnitTest(ClassUnderTest.class);

    assertNotNull(unitTest.getUsage());

  }

}

At least to me, this does not seem very readable. If I want to understand what the unit test is trying to tell me, I have to read it word by word. Compared to normal text, reading unit test code is a lot slower. If the tests were more readable, would it cause people to pay more attention to them and keep them as sharply refactored and intentional as the actual code? I was thinking of a tool that would reformat the test code to be more readable. How about something along the following:

This could be completely generated from the unit test code. All it takes is that the people make unit test names as describing as possible.