while(coding){DoTDD();}

Testing Java Console Applications

2011-12-21T16:52:00.022+01:00

Currently I'm reading the great book "Growing Object-Oriented Software, Guided by Tests" by Steve Freeman and Nat Pryce. They encourage us to drive software development in the large with an outer loop of end-to-end acceptance tests and in the small with an inner loop of unit tests. While implementing just for fun the Nine Men's Morris board game with a simple console user interface, I tried to get a feeling for "test guided growing of software" as it is described in the book.

During that exercise I needed to find a solution to control the input towards and the output from the console. The following example source code shows one possible solution.

I started with an acceptance test. I choose to implement it with JUnit, but Fitnesse tool would have been an alternative.

public class NineMensMorrisAcceptanceTests {

  private ApplicationRunner application = new ApplicationRunner();
  
  @Test
  public void applicationAsksForUserMoveAndThenMakesOwnMove()
  {
    application.startGame();
    application.hasDisplayed("Nine Men's Morris");
    application.hasDisplayed("Please enter spot to place piece:");
    application.userEnters("1\r\n");
    application.hasDisplayed("Computer places piece on spot: 2");
  }
}

The ApplicationRunner class starts the console application in a new thread and acquires control over the input and output streams. Luckily Java has such a well designed IO system, which allows easy test set up. The game application writes to the console via System.out and reads from the console via System.in:

public class ApplicationRunner {

  private PipedOutputStream pipedOutputStream;
  private PipedInputStream pipedInputStream;
  private ByteArrayOutputStream outputStream;

  public ApplicationRunner(){
    pipedOutputStream = new PipedOutputStream();
    pipedInputStream = new PipedInputStream(pipedOutputStream);
    System.setIn(pipedInputStream);

    outputStream = new ByteArrayOutputStream();
    System.setOut(new PrintStream(outputStream));
  }
 
  public void startGame() {
    Thread thread = new Thread("Test Application"){
      @Override public void run(){Console.main(null);}
    };
    thread.setDaemon(true);
    thread.start();
  }

  public void hasDisplayed(String text) {
    boolean displayed = false; int tries = 20;
    while(tries>0 && !displayed){
      Thread.sleep(100);
      displayed = outputStream.toString().contains(text) ? true : false;
      tries--;
    }
    if (!displayed){
      throw new AssertionError("Missing text in output: " + text);
    }
  }

  public void userEnters(String userInput) {
    pipedOutputStream.write(userInput.getBytes());
  }
}

The Console.main() method set ups and starts the console application:

public static void main(String[] args) {
  ConsoleGameUI consoleGameUI = new ConsoleGameUI();
  GameController controller = new GameController(
    consoleGameUI, 
    new Engine(),
    new MoveGenerator());
  consoleGameUI.init(new InputParser(),controller);
  controller.start();
}

When we develop the ConsoleGameUI class, we will write some unit tests. There we can use also the hijacked streams to control inputs and outputs. Because this time the test runs synchronously we can use a ByteArrayInputStream instead of PipedInputStream to supply the user input to the system under test:

public class ConsoleGameUITests {
 
  // Class under test
  ConsoleGameUI consoleGameUI;

  private String userInput;
  private ByteArrayInputStream inputStream;
  private ByteArrayOutputStream outputStream;
  ...
 
  @Before public void setUp() {
    userInput = "some input from user";
    inputStream = new ByteArrayInputStream(userInput.getBytes());
    outputStream = new ByteArrayOutputStream();
    System.setIn(inputStream);
    System.setOut(new PrintStream(outputStream));
    ... 
    consoleGameUI = new ConsoleGameUI();
    consoleGameUI.init(inputParserMock, gameControllerMock);
  }
 
  @Test public void shouldPromptTheUserToEnterSpotToPlaceAPiece(){
    consoleGameUI.askUserForMove(Turn.PLACE_WHITE);
    assertTrue(outputStream.toString().contains("Please enter spot to place piece:"));
  }

  @Test public void shouldPromptTheUserToEnterSpotsToSlidePiece(){
    consoleGameUI.askUserForMove(Turn.SLIDE_WHITE);
    assertTrue(outputStream.toString().contains("Please enter spots to slide piece:"));
  }

  @Test public void shouldReadInputAndCallParser()
  {
    context.checking(new Expectations() {{
      oneOf(inputParserMock).Parse(userInput);
      ...  
    }});
    consoleGameUI.askUserForMove(Turn.PLACE_WHITE);
    context.assertIsSatisfied();
  }
  ...
}

In the ConsoleGameUI class we use System.out and System.in:

public class ConsoleGameUI implements GameUI {

  private final Scanner scanner;
  private IInputParser parser;
  private IGameController gameController;
 
  public ConsoleGameUI(){
    this.scanner = new Scanner(System.in);
  }
 
  public void init(IInputParser parser, IGameController gameController){...}
 
  @Override
  public MoveRequest askUserForMove(Turn turn) {
    switch(turn){
    case PLACE_WHITE:
      System.out.print("Please enter spot to place piece:"); 
      break;
    case SLIDE_WHITE:
      System.out.print("Please enter spots to slide piece:");
      break;
    ...  
    String line = scanner.nextLine();
    MoveRequest request = parser.Parse(line);
    return request;
  }
  ...
}

Rhino Mocks Arrange / Act / Assert (AAA) Syntax Quick Reference

2011-02-25T17:04:00.016+01:00

Recently I held a training session about Test-Driven Development(TDD) for .NET developers. A important part in this training was about Mocking, which is essential when you apply TDD to the real world. I presented several examples with Rhino Mocks and used the brilliant AAA syntax of Rhino Mocks. As supporting material for the practical exercises of the participants I missed a quick reference for this syntax style. Based on Ayende's article Rhino Mocks 3.5 and the Rhino Mocks 3.3 Quick Reference I created a new document with code examples:

Rhino Mocks AAA Syntax Quick Reference on Google Docs Rhino Mocks AAA Syntax Quick Reference on Scribd

'Design By Contract' Metrics

2010-11-04T13:59:00.006+01:00

We are currently introducing 'Design By Contract' to a software development group of about 60 developers, which are developing different components. We started by defining 'Design By Contract' policies for C# and Java. It is quite challenging to manage this change effort.

One piece of the change strategy is to measure the progress. We are counting the number of classes and the number of contract assertions (Preconditions, post conditions and invariants). So we have two statistics:

Absolut number of contract assertions per component
Average number of contract assertions per class per component

The metrics tell us whether contracts are "at all" be used. We want to increase the code quality with contracts. If we see a team not implementing any contracts or only very few, we can support the team with training and consulting.

The metrics are published on a regular basis and serve as a means for motivation.

The limitation of thise metrics is, that they do not tell whether a component has enough contracts, so its understandability, maintainability and so on is best supported with 'Design By Contract'. Quality of contracts is not covered by the metrics.

Example for parsing C# code with the NRefactory library

2010-10-28T23:04:00.010+02:00

NRefactory is part of the open source IDE SharpDevelop for the .NET platform. NRefactory is a parser library for C# and VB. It can create an Abstract Syntax Tree (AST) that represents all constructs that are available in C# or VB. This AST can be used to analyze source code or to modify and generate code again.

You can download the SharpDevelop IDE, install it and then find the ICSharpCode.NRefactory.dll in the bin folder of the installation. Or you download the SharpDevelop source code and compile the dll yourself.

The example below shows how to parse C# source code files, generate an AST and then using the AST to create metrics about the number of classes and the number of Code Contracts.

using System;
using System.IO;
using System.Diagnostics.Contracts;
using ICSharpCode.NRefactory;
namespace ContractCounter
{
  class Program
  {
    public static void Main(string[] args)
    {
      TextReader reader = File.OpenText("Program.cs");
      using (IParser parser = ParserFactory.CreateParser(SupportedLanguage.CSharp, reader))
      {
        parser.Parse();
        if (parser.Errors.Count <= 0)
        {
          // Here we will use the parser.CompilationUnit(AST)
          ...
        }
        else
        {
          Console.WriteLine("Parse error: " + parser.Errors.ErrorOutput);
        }
      }
      Console.Write("Press any key to continue . . . ");
      Console.ReadKey(true);
    }
  }
}

To traverse the AST we can use the Visitor pattern (see [Gamma et.al:Design Patterns]. We implement a new visitor 'CounterVisitor' for our purposes. We can inherit from the predefined 'AbstractAstVisitor'. In NRefactory visitors are responsible for traversing the AST by themselfs so we have to call the children when we are visiting certain node types:

using System.Diagnostics.Contracts;
using ICSharpCode.NRefactory.Ast;
using ICSharpCode.NRefactory.Visitors;
namespace ContractCounter
{
  public class CounterVisitor : AbstractAstVisitor
  {
    public override object VisitCompilationUnit(CompilationUnit compilationUnit, object data)
    {
      Contract.Requires(compilationUnit != null);
      
      // Visit children (E.g. TypeDcelarion objects)
      compilationUnit.AcceptChildren(this, data);
      
      return null;
    }

    public override object VisitTypeDeclaration(TypeDeclaration typeDeclaration, object data)
    {
      Contract.Requires(typeDeclaration != null);
      
      // Is this a class but not a test fixture?
      if (IsClass(typeDeclaration) && !HasTestFixtureAttribute(typeDeclaration))
      {
        classCount++;
      }

      // Visit children (E.g. MethodDeclarion objects)
      typeDeclaration.AcceptChildren(this, data);
      
      return null;
    }

    public override object VisitMethodDeclaration(MethodDeclaration methodDeclaration, object data)
    {
      Contract.Requires(methodDeclaration != null);

      // Visit the body block statement of method declaration
      methodDeclaration.Body.AcceptVisitor(this, null);

      return null;
    }

    public override object VisitBlockStatement(BlockStatement blockStatement, object data)
    {
      Contract.Requires(blockStatement != null);

      // Visit children of block statement (E.g. several ExpressionStatement objects)
      blockStatement.AcceptChildren(this, data);

      return null;
    }

    public override object VisitExpressionStatement(ExpressionStatement expressionStatement, object data)
    {
      Contract.Requires(expressionStatement != null);

      // Visit the expression of the expression statement (E.g InnvocationExpression)
      expressionStatement.Expression.AcceptVisitor(this, null);

      return null;
    }

    public override object VisitInvocationExpression(InvocationExpression invocationExpression, object data)
    {
      Contract.Requires(invocationExpression != null);

      // Visit the target object of the invocation expression (E.g MemberReferenceExpression)
      invocationExpression.TargetObject.AcceptVisitor(this, null);
      return null;
    }

    public override object VisitMemberReferenceExpression(MemberReferenceExpression memberReferenceExpression, object data)
    {
      Contract.Requires(memberReferenceExpression != null);

      IdentifierExpression identifierExpression = memberReferenceExpression.TargetObject as IdentifierExpression;

      // Is this a call to Contract.Requires(), Contract.Ensures() or Contract.Invariant()?
      if ( identifierExpression != null &&
          identifierExpression.Identifier == "Contract" &&
          (memberReferenceExpression.MemberName == "Requires" ||
           memberReferenceExpression.MemberName == "Ensures" ||
           memberReferenceExpression.MemberName == "Invariant") )
      {
        assertionCount++;
      }

      return null;
    }

    public int ClassCount {
      get { return classCount; }
    }

    public int AssertionCount
    {
      get { return assertionCount; }
    }

    #region private members
    private int classCount;
    private int assertionCount;

    static private bool IsClass(TypeDeclaration typeDeclaration)
    {
      return typeDeclaration.Type == ClassType.Class;
    }

    static private bool HasTestFixtureAttribute(TypeDeclaration typeDeclaration)
    {
      bool hasTestFixtureAttribute = false;
      foreach (AttributeSection section in typeDeclaration.Attributes) {
        foreach (Attribute attribute in section.Attributes) {
          if (attribute.Name == "TestFixture") {
            hasTestFixtureAttribute = true;
            break;
          }
        }
      }
      return hasTestFixtureAttribute;
    }
    #endregion
  }
}

The actual counting takes place in the VisitTypeDeclaration() and the VisitMemberReferenceExpression() methods. All other methods are just neccesary for traversing the tree. We now have to start the vistor to traverse the AST in the Main() method:

...
// Here we will use the parser.CompilationUnit(AST)
CounterVisitor visitor = new CounterVisitor();
parser.CompilationUnit.AcceptVisitor(visitor, null);
Console.WriteLine("The file contains " + visitor.ClassCount + " class(es)");
Console.WriteLine("The file contains " + visitor.AssertionCount + " contract(s)");
...

For exploring the structure of the NRefactory AST you can use the NRefactoryDemo application, which is part of the SharpDevelop source code. You can enter source code and let the application create the according AST:

Stubs vs Mocks with Rhino Mocks

2009-11-29T20:27:00.021+01:00

Recently I was asked: "What is the difference between Stubs and Mocks?" Martin Fowler has written a good article about that topic "Mocks Aren't Stubs". Also in the Rhino Mocks Wiki there is is comprehensive explanation.

Besides the theoretical aspect you have to decide whether to use

MockRepository.GenerateMock or

MockRepository.GenerateStub

when you use the "Arrange, Act, Assert" syntax of Rhino Mocks. To find out the detailed differences I wrote some tests, which are all green. I defined expected behaviour or stubbed behaviour with different syntax combinations. The behaviour is not called in any test. Only in the tests with the "ExpectedException" attribute RhinoMocks throws an exception:

[Test]
[(typeof(ExpectationViolationException))]
public void VerifyAllExpectationsWithExpectMethodOnMock()
{
   IList listMock = MockRepository.GenerateMock<IList>();
   listMock.Expect(x => x.Count).Return(10);

   listMock.VerifyAllExpectations();
}

[Test]
public void VerifyAllExpectationsWithExpectMethodOnStub()
{
   IList listStub = MockRepository.GenerateStub<IList>();
   listStub.Expect(x => x.Count).Return(10);

   listStub.VerifyAllExpectations();
}

[Test]
public void VerifyAllExpectationsWithStubMethodOnMock()
{
   IList listMock = MockRepository.GenerateMock<IList>();
   listMock.Stub(x => x.Count).Return(10);

   listMock.VerifyAllExpectations();
}

[Test]
public void VerifyAllExpectationsWithStubMethodOnStub()
{
   IList listStub = MockRepository.GenerateStub<IList>();
   listStub.Stub(x => x.Count).Return(10);

   listStub.VerifyAllExpectations();
}

[Test]
[ExpectedException(typeof(ExpectationViolationException))]
public void AssertWasCalledWithMock()
{
   IList listMock = MockRepository.GenerateMock<IList>();

   listMock.AssertWasCalled(x => { int temp = x.Count; });
}

[Test]
[ExpectedException(typeof(ExpectationViolationException))]
public void AssertWasCalledWithStub()
{
   IList listStub = MockRepository.GenerateStub<IList>();

   listStub.AssertWasCalled(x => { int temp = x.Count; });
}

The conclusion from these tests are: If you need a mocking behaviour in Rhino Mocks that verifies your code under test, you have to use one of these two combinations of methods:

GenerateMock with Expect(...) and VerifyAllExpectations()
GenerateMock/GenerateStub with AssertWasCalled(...)

LightContracts is a simple, small and lightweight library supporting 'Design by Contract'

2009-10-12T23:26:00.004+02:00

Recently I created a project on Codeplex.com. It is called LightContracts and is a simple, small and lightweight library supporting 'Design by Contract' style of programming. It let you specify simple pre- and postconditions with a fluent API, without using an heavy AOP framework. It is developed in C#. In his famous book "Object-Oriented Software Construction" Bertrand Meyer described a design technique called "Design by Contract" (DBC) which can improve software quality dramatically. His programming language Eiffel supports this design technique inherently. This valuable technique is universal and widely accepted and can be used regardless in which programming language you are developing. There are several tools available to use "Design By Contract" on the .NET platform ( E.g. ContractDriven.NET or ContractN). Recently Microsoft announced that its Code Contracts projects would be included as part of .Net 4.0.

So why should I use LightContracts?

All mentioned projects are quite heavyweight. They are using aspect-oriented programming (AOP) frameworks to inject code, require to inherit from a base class or need special tools and compiler settings. My observation is that 90% of all assertions are very simple and do not justify the use of heavy tools. LightContracts is a small DLL which can simply be referenced by any .NET project, without installing additional software. It has a fluent API which allows reading pre- and postconditions nearly like natural language. This allows simply copying these assertions into the method comments.

What is Design by Contract?

2009-02-11T21:55:00.020+01:00

This is the first article in a series which I started after I reasoned about "Why is Design by Contract not common practice in Software Enineering?".

Design by Contract is a technique to specify the behavior of a class. It helps to communicate what effects methods will have and what the methods expect before they can be executed. Design by Contract means that the caller of a class and the class itself make a contract, which is described as a set of assertions called Preconditions, Postconditions and Invariants.

So the interface and the implementation of a class is enhanced with additional assertions. Preconditions define obligations for the caller of a method, which have to be satisfied before the method is called. Postconditions will guarantee the outcome of the method. Invariants apply to the class as a whole and define conditions which are valid at the end of each method call.

I show an example in C# for preconditions and postconditions. Preconditions are commonly describes with the term 'require' and postconditions with the term 'ensure'. The property PrinterNames has the postcondition that the delivered list is not null. The method RemovePrinter has three preconditions:

public class Printers
{
    private List<string> names;
    
    public Printers()
    {
        names = new List<string>();
        names.Add("printer1");
        names.Add("printer2");
    }
    
    /// <summary>
    /// List of printer names.
    /// Assertion.Ensure(names != null,"Result is not null");
    /// </summary>
    public List<string> PrinterNames
    {
        get
        {
            Assertion.Ensure(names != null,"Result is not null");
            return names;
        }
    }
    
    /// <summary>
    /// Remove a printer
    /// Assertion.Require(PrinterNames().Count > 0,"There is at least one printer");
    /// Assertion.Require(printerIndex >= 0,"printerIndex is not negative");
    /// Assertion.Require(printerIndex lessThan PrinterNames().Count ,"printerIndex is in range");
    /// </summary>
    public void RemovePrinter(int printerIndex)
    {
        Assertion.Require(PrinterNames.Count > 0,"There is at least one printer");
        Assertion.Require(printerIndex >= 0,"printerIndex is not negative");
        Assertion.Require(printerIndex < PrinterNames.Count ,"printerIndex is in range");
    
        names.RemoveAt(printerIndex);
    }

    ...
}

For further information about Design by Contract please refer to the Eiffel web site or the book Object-Oriented Software Construction

In the next article I will try to answer the question: What are the benefits of Design by Contract?

Why is Design by Contract not common practice in Software Enineering

2009-02-04T14:35:00.007+01:00

Concerned with a lot of source code reviews over the last years, I have recognized that Design by Contract is not a common practice in Software Engineering. Nearly all C++, Visual Basic, Java and C# source code I saw was designed and written without applying Design by Contract. Thinking about the reasons for programmers not to use Design by Contract I made a list with questions they may have:

What is Design by Contract?
What are the benefits of Design by Contract?
Do I need to use Eiffel as my programming language to apply Design by Contract?
Do I have to spend a lot of effort for Design by Contract?
In which situations should I use Design by Contract?
Does Design by Contract conflict with other design and implementation techniques like TDD and DDD?

If you have no or wrong answers for these questions you will probably not use Design by Contract in your day to day programming work. I will try to answer these questions in a series of articles and hope it will convince more programmers that Design by Contract is an elegant technique to improve software quality.

Preconditions, Postconditions: Design by Contract for C#

2009-01-15T23:50:00.009+01:00

Bertrand Meyer has described a design technique called "Design by Contract" (DBC) in his book Object-Oriented Software Construction. He also added support for this technique in his programming language Eiffel. Also other languages do not have a native support for this valuable technique, we nevertheless can apply this technique in all other languages. What we need is the possibility to define and execute assertions at runtime and we have to document the pre-, and postconditions in the header of our methods. For C# we only need a small helper class (comments are omitted):

public static class Assertion
{
    public static void Require(bool precondition, string conditionDescription)
    {
        if (!precondition)
        {
            throw new AssertException(ExceptionDescription("Precondition", conditionDescription));
        }
    }

    public static void Require(bool precondition, string descriptionFormat, params object[] descriptionParameters)
    {
        if (!precondition)
        {
            throw new AssertException(ExceptionDescription("Precondition", string.Format(CultureInfo.InvariantCulture, descriptionFormat, descriptionParameters)));
        }
    }

    public static void RequireIsNotNull(object toBeTested,string objectName)
    {
        if (toBeTested==null)
        {
            throw new AssertException(ExceptionDescription("Precondition", objectName + " is not null"));
        }
    }

    public static void Ensure( bool postcondition, string conditionDescription )
    {
        if ( ! postcondition )
        {
            throw new AssertException(ExceptionDescription("Postcondition",conditionDescription));
        }
    }

    public static void Ensure( bool postcondition, string descriptionFormat, params object[] descriptionParameters )
    {
        if ( ! postcondition )
        {
            throw new AssertException(ExceptionDescription("Postcondition",string.Format( CultureInfo.InvariantCulture, descriptionFormat, descriptionParameters ) ) );
        }
    }


    public static void Check( bool condition, string conditionDescription )
    {
        if ( ! condition )
        {
            throw new AssertException(ExceptionDescription("Condition",conditionDescription));
        }
    }

    public static void Check( bool condition, string descriptionFormat, params object[] descriptionParameters )
    {
        if ( ! condition )
        {
            throw new AssertException(ExceptionDescription("Condition",string.Format( CultureInfo.InvariantCulture, descriptionFormat, descriptionParameters ) ) );
        }
    }


    //
    // Private methods
    //

    private static string ExceptionDescription(string assertionType, string description)
    {
        return string.Format(CultureInfo.InvariantCulture, "{0} failed. The expectation was '{1}', but this is false.", assertionType, description);
    }

}

As important as checking the assertions at runtime is to allow a client of our class to read the preconditions and postconditions without inspecting the implementation of our methods. The simplest solution is to copy the assertions into then method comments:

public class PrinterDescription
{
    private XmlDocument printerXml;

    /// <summary>
    /// Load the descripton from a xml file
    /// Assertion.RequireIsNotNull(printerDescriptionPath, "printerDescriptionPath");
    /// Assertion.Require(File.Exists(printerDescriptionPath), "File printerDescriptionPath exists");
    /// Assertion.Ensure(IsLoaded, "IsLoaded");
    /// </summary>
    public void Load(string printerDescriptionPath)
    {
        Assertion.RequireIsNotNull(printerDescriptionPath, 
            "printerDescriptionPath");
        Assertion.Require(File.Exists(printerDescriptionPath), 
            "File printerDescriptionPath exists");

        printerXml = new XmlDocument();
        printerXml.Load(printerDescriptionPath);

        Assertion.Ensure(IsLoaded, "IsLoaded");
    }

    /// <summary>
    /// Is the description loaded?
    /// </summary>
    public bool IsLoaded
    {
        get
        {
            return printerXml != null;
        }
    }

    /// <summary>
    /// Name of the printer
    /// Assertion.Require(IsLoaded, "IsLoaded");
    /// </summary>
    public string Name
    {
        get
        {
            Assertion.Require(IsLoaded, "IsLoaded");
            XPathNavigator nameNode = printerXml.CreateNavigator().SelectSingleNode("//PrinterName");
            return nameNode.Value;
        }
    }

}

Preconditions, Postconditions, Invariants : Design by Contract for Java #2

2008-12-18T00:00:00.017+01:00

Recently I wrote about how to apply "Design by Contract" with Java. I proposed to use the assert statement of java, in case you do not want to set up some external tools like Contract4J, iContract or Jass. After using the assert statement for a while I would recommend to use your own implementation of assertions instead like this:

public class Assertion {

 /**
  * Precondition.
  * @param condition we expect to be true.
  * @param description repeats the condition or describes it in
  * other words.
  */
 public static void Require(boolean condition, String description) {
     if (!condition) {
         throw new RuntimeException("Precondition: The expectation '" + description + "' is violated");
     }
 }

 /**
  * Precondition.
  * @param objectToBeTested is an object we expect to be not null
  * @param objectName is the name of the variable we test.
  */
 public static void RequireNotNull(Object objectToBeTested,String objectName) {
     if (objectToBeTested == null) {
         throw new RuntimeException("Precondition: The expectation '" + objectName + " is not null' is violated");
     }
 }

 /**
  * Postcondition.
  * @param condition we expect to be true.
  * @param description repeats the condition or describes it in
  * other words.
  */
 public static void Ensure(boolean condition, String description) {
     if (!condition) {
         throw new RuntimeException("Postcondition: The expectation '" + description + "' is violated");
     }
 }

 /**
  * Common condition to be used in the middle of methods
  * @param condition we expect to be true.
  * @param description repeats the condition or describes it in
  * other words.
  */
 public static void Check(boolean condition, String description) {
     if (!condition) {
         throw new RuntimeException("Condition: The expectation '" + description + "' is violated");
     }
 }
}

Why is the own implementation better than the assert statement?

It does not make sense to switch off the runtime checks of assertions. We use assertions to simplify and avoid the error handling code in our methods. When it is possible to switch of assertions we loose this advantage, because we have to prepare our code to handle situations where the assertions are not checked.
We are not only profiting from assertions during development and testing but also when the software is deployed. Assertions uncover error conditions much clearer and with better error descriptions. The logs in a production system will contain the messages from assertions and will help to find the cause of the problem much faster. If we switch off the assertions the problems will occurring much later and the cause of the problem can only be found with much more effort,

You can find details about "Design by Contract" in the famous book Object-Oriented Software Construction by Bertrand Meyer.

Mocking an object with two interfaces

2008-12-15T10:58:00.006+01:00

Currently I spend a lot of time with maintaining 'legacy' java code. That is not really funny :-(. To make the most out of it, I write as much unit tests as possible to gain some more confidence in the code and be prepared for future bugfixes and refactorings. I stumbled over a small problem, when I tried to mock an object which implements two interfaces. My 'system under test'(SUT) class TextManager uses an object which is an IReader and an IWriter at the same time. The object is only handed over once and the TextManager has to cast the IReader object into an IWriter object. The whole design is not really outstanding (to be polite) and I would have implemented it myself a little bit different.

public class TextManager {
   
   private IReader reader;
   
   public void readAndWrite() {
      String text = reader.read();
      text = "*" + text + "*";
      ((IWriter)reader).write(text);
   }
}

I wrote a unit test for the readAndWrite() method and recognized that I can't simply create a jMock object for the IReader/IWriter object. My colleague Henning found a simple an effective solution. In my test package I create a new interface called IReaderWriter which extends IReader and IWriter. Now I can create a mock object for this new interface which is able to work as a test double inside TextManager:

public void testReadAndWrite() {
    
    // Setup
    final IReaderWriter mock = context.mock(IReaderWriter.class);
    TextManager textManager = new TextManager(mock);
    context.checking(new Expectations() {{
        one(mock).read(); will(returnValue("test"));
        one(mock).write("*test*");
    }});
    
    // Exercise
    textManager.readAndWrite();
    
    // Verify
    context.assertIsSatisfied();
}

Preconditions, Postconditions, Invariants : Design by Contract for Java

2008-11-27T21:40:00.038+01:00

In his famous book Object-Oriented Software Construction Bertrand Meyer described a design technique called "Design by Contract" (DBC) which can improve software quality dramatically. His programming language Eiffel supports this design technique inherently. This valuable technique is universal and widely accepted and can be used regardless in which programming language you are developing. To apply this technique in Java you need to define and execute assertions at runtime. The pre-, and postconditions of a method should also be part of the javadoc documentation.

There are a lot of tools and framework which help you to apply DBC to your Java code. For example OVal, Contract4J, which are using AspectJ, iContract or Jass, which are using a preprocessor for Java.

In some circumstances it might be too much effort to apply one of these tools to you development project. Luckily there was a rudimentary support for testing assertions added to the Java language starting with release 1.4. The assert statement allows to define runtime checks inside your code. With some simple conventions you can benefit from DBC without heavy tool support. Here is an example how to use the assertion mechanism of Java to apply "Design by Contract":

/**
* Is the editor in the edit mode?
* @return True, if the editor is in the edit mode. Otherwise false.
*/
public boolean isInEditMode() {
 ...
}

/**
* Sets a new text.
* Precondition: isEditMode()
* Precondition: text != null
* Postcondition: getText() == text
* @param name
*/
public void setText(String text) {
 assert isInEditMode() : "Precondition: isInEditMode()";
 assert text != null : "Precondition: text != null";

 this.text = text;

 assert getText() == text : "Postcondition: getText() == text";
}


/**
* Delivers the text.
* Precondition: isEditMode()
* Postcondition: result != null
* @return
*/
public String getText() {

 assert isInEditMode() : "Precondition: isInEditMode()";

 String result = text;

 assert result != null : "Postcondition: result != null";
 return result;
}

So you can use "Design by Contract" effectively with three simple rules:

Use the assert mechanism of Java to check preconditions, postconditions and invariants at runtime.
Describe each assert with a string that starts either with "Precondition:", "Postcondition:" or "Invariant:" followed by the textual description of the assert expression.
Add each assert description string to the javadoc comment of the method

We can get a little more support, when we write our own pre- and postcondition class:

public class Assertion {

   /**
    * Precondition.
    * @param condition we expect to be true.
    * @param description repeats the condition or describes it in
    * other words.
    */
   public static void Require(boolean condition, String description) {
       if (!condition) {
           throw new RuntimeException("Precondition: The expectation '" + description + "' is violated");
       }
   }
  
   /**
    * Precondition.
    * @param objectToBeTested is an object we expect to be not null
    * @param objectName is the name of the variable we test.
    */
   public static void RequireNotNull(Object objectToBeTested,String objectName) {
       if (objectToBeTested == null) {
           throw new RuntimeException("Precondition: The expectation '" + objectName + " is not null' is violated");
       }
   }

   /**
    * Postcondition.
    * @param condition we expect to be true.
    * @param description repeats the condition or describes it in
    * other words.
    */
   public static void Ensure(boolean condition, String description) {
       if (!condition) {
           throw new RuntimeException("Postcondition: The expectation '" + description + "' is violated");
       }
   }

   /**
    * Common condition to be used in the middle of methods
    * @param condition we expect to be true.
    * @param description repeats the condition or describes it in
    * other words.
    */
   public static void Check(boolean condition, String description) {
       if (!condition) {
           throw new RuntimeException("Condition: The expectation '" + description + "' is violated");
       }
   }
}

Using this class instead of 'assert' has the advantage that we can't forget to switch on the runtime checking of the assertions with -enableassertions. But keep in mind you still have to add method comments for the assertions. This is important, because the assertions should help the users of your class without forcing them to read your implementation details:

/**
* Sets a new text.
* Require: isEditMode()
* Require: text != null
* Ensure: getText() == text
* @param name
*/
public void setText(String text) {
 Assertion.Require(isInEditMode(),"isInEditMode()");
 Assertion.RequireNotNull(text, "text");

 this.text = text;

 Assertion.Ensure(getText() == text,"getText() == text");
}


/**
* Delivers the text.
* Require: isEditMode()
* Ensure: result != null
* @return
*/
public String getText() {

 Assertion.Require(isInEditMode(),"isInEditMode()");

 String result = text;

 Assertion.Ensure( result != null, "result != null";
 return result;
}

There is also an article "Using Assertions in Java Technology" on the Sun Developer network. See "Preconditions, Postconditions, Invariants : Design by Contract for Java #2" for further infos.

CruiseControl, ClearCase and Dynamic Views

2008-10-28T20:26:00.008+01:00

When I set up CruiseControl in our development infrastructure, I struggled a little bit with the ClearCase integration. I got a lot of information from the very good book Kevin A. Lee: IBM Rational(R) ClearCase(R), Ant, and CruiseControl: The Java(TM) Developer's Guide to Accelerating and Automating the Build Process. Unfortunately the book is not explicit whether to use dynamic or snapshot views in conjunction with CruiseControl. In our project most of the developers are using dynamic views to set up their private workspaces. So I tried to use dynamic views as well for CruiseControl. That was not a brilliant idea. Whats the problem? When I set up CruiseControl as a windows service, I put the CruiseControl configuration file 'config.xml' into ClearCase. I recognized that the dynamic view with the 'config.xml' is not accessible by the service. Dynamic views have to be started with a cleartool command and then are mapped as drives. That must happen before the windows service is started. That seems not an straight forward solution when you are using the Java Service Wrapper. Also mapped drives are not accessible by a windows service as long as no user is logged on. You can't use the drive letter, instead you have to use an URL. In the end it was much easier to set up CruiseControl with a snapshot view.

TDD and Layered Architecture

2008-08-26T22:34:00.010+02:00

I just read the blog post of Jeffrey Palermo about the Onion Architecture (see also the similar pattern Hexagonal architecture). Aspects of this patterns are used in an architecture our team defined for a healthcare information system.

Interesting is Jeffrey's rationale for moving certain components to the outer layer: The "infrastructure is pushed out to the edges where no business logic code couples to it", because "this code is most likely to change frequently as the application goes through years of maintenance". I think this is absolutely true.

Eric Evans presented a pattern called Layered Architecture in his book Domain-Driven Design: Tackling Complexity in the Heart of Software. His rationale for for moving certain components to the outer layer: The domain model should be separated from the technical details so it contains only the concepts we want to discuss with the domain experts. That is also a very good guideline when we have decide in which layer a certain piece of code belongs.

A third rational for moving certain components to the outer layer we get when we are using TDD: All components which can't be tested by pure unit tests should be placed on the outer layer. These components should be as thin as possible, because we want to test as much code as possible by pure unit tests. Components which do not have an API defined in the implementation language like GUI components, Windows Services, Wrapper to other languages and platforms and so on are candidates for the outer layer. Here we can't use pure unit tests. Slower or more awkward tests type have to be used. Data access components for databases contain or generate SQL statements. These data access components should be tested in conjunction with the real database to verify the correctness of the SQL statements. I call these tests database unit tests. They are much slower than the pure unit tests.

Configure CruiseControl Logging

2008-07-25T11:51:00.030+02:00

If you have problems to get your CruiseControl running you may want to see some more log output. For example when your < modificationset> configuration does not work as expected, you want to see which commands are submitted for retrieveing the modifications in your source code repository. To switch on more log output create a log4j.properties file and place it in the CruiseControl folder side by side with the CruiseControl.bat and the config.xml file. The file may contain a log4j configuration like:

# Set root logger level to ERROR (default)
log4j.rootLogger=ERROR, CONSOLE, FILE
log4j.logger.net.sourceforge.cruisecontrol=INFO
log4j.logger.net.sourceforge.cruisecontrol.sourcecontrols=DEBUG

# A1 is to console
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d [%-9t] %-5p %-14.14c{1}- %m%n

# FILE is file logger with rotation
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d [%-9t] %-5p %-14.14c{1}- %m%n
log4j.appender.FILE.File=cruisecontrol.log
log4j.appender.FILE.MaxFileSize=5000KB
log4j.appender.FILE.MaxBackupIndex=4

Modify the CruiseControl.bat which starts the CruiseControl build loop. Add the command line parameter "-Dlog4j.configuration=file:./log4j.properties" to the call of the java application:

set CCDIR=%~dp0

:checkJava
if not defined JAVA_HOME goto noJavaHome
set JAVA_PATH="%JAVA_HOME%\bin\java"
set CRUISE_PATH=%JAVA_HOME%\lib\tools.jar
goto setCruise

:noJavaHome
echo WARNING: You have not set the JAVA_HOME environment variable. Any tasks relying on the tools.jar file (such as "< javac>") will not work properly.
set JAVA_PATH=java

:setCruise
set LIBDIR=%CCDIR%lib

set LAUNCHER=%LIBDIR%\cruisecontrol-launcher.jar

set EXEC=%JAVA_PATH% %CC_OPTS% -Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder -Dlog4j.configuration=file:./log4j.properties -jar "%LAUNCHER%" %* -jmxport 8001 -webport 8080 -rmiport 1099
echo %EXEC%
%EXEC%

With this setup you get more detailed output concerning the access towards the source code repository.

A New xUnit Test Pattern

2008-05-22T21:13:00.029+02:00

Inspired by the Gerard Meszaros book xUnit Test Patterns: Refactoring Test Code, I have written down a pattern, which I used already many times:

Own Library Interface

Also known as: 'Skin and Wrap the API' [Working Effectively with Legacy Codeby Michael Feathers]

How can we make a code testable, when the code depends on a library class, which can't be replaced by a 'Test Double'?

We write our own interface that exactly mirrors the API of the library class. In our system under test (SUT) we use the interface instead of the library class itself.

The code we want to test is the system under test (SUT). It references a depended-on component (DOC) library class.

Some library classes do not inherit from an interface, they do not declare their methods as virtual or they provide static methods, so it is not possible to introduce a Test Double to the SUT via Dependency Injection or Dependency Lookup to replace the library class during testing. This problem arises very often when we need to use system or third party libraries (like the .NET framework) where we can’t modify the library classes and have to use them as they are. Library designers prefer to use class-based APIs instead of interfaces, because they can be evolved in later versions of the library. If they want to add members to a library interface in a later version , they would break existing code [Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Librariesby Abrams and Cwalina]. Very often the SUT can’t be tested together with the library class, because the library class can’t be used in the test environment. The reason may be that the library class will not return values needed for the test or executing it would have undesirable side effects.

How it Works

We write our own interface which mirrors the API of a library class we are using in our SUT. Our own interface does not need to contain the complete API of the library class but may contain only the subset we are requiring for our SUT. We implement a thin wrapper for the library class which inherits from our own interface. The wrapper will contain no logic. Each method can simply be forwarded to the library class, because the signatures of our own interface are the same as the library class. The SUT must use the interface instead of the library class itself. The SUT will be initialized with a concrete object via Dependency Injection or Dependency Lookup. In the production environment the thin wrapper is used. In the test environment we can replace the thin wrapper with a Test Double.

When to Use It

We have to use the Own Library Interface when we use a third party library class in our SUT which has both of the two following characteristics:

The dependency on the library class prevents us from executing the SUT in a test environment. It may be plain impossible, too slow, too complex or too expensive to prepare a test environment for testing the SUT together with the library class.
The library class can not be replaced by a Test Double, because it does not inherit from an interface, it does not declare its methods as virtual or it has static methods.

These circumstances very often lead to the smell Developers Not Writing Tests. The SUT will be declared as untestable. Also TDD beginners often stumble over this problem and get the impression that TDD is not applicable to real world examples.

Implementation Notes

Library classes which define the API for operating system mechanisms (registry, event log, services), the API for hardware sub systems (network infrastructure) or the API to other software components (SMTP server, POP3 server) are candidates for the usage of the Own Library Interface pattern. Preparing a fixture for testing own classes which are using such library classes may be plain impossible, too slow, too complex or too expensive. See TDD for Beginners as an detailed example for the usage of the Own Library Interface pattern. We do not need to use the Own Library Interface pattern, when we can test our SUT together with the library class. For example the File or Directory classes from the .NET framework can easily be tested together with the SUT, because preparing files and directories during test setup as well as checking them after exercising the SUT is quite easy.

To become a better programmer

2008-04-19T23:53:00.015+02:00

I think some books might help to become a better programmer. This is my personal list:

Erich Gamma, Richard Helm, Ralph Johnson, and John M. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)

The book came out, when I finished university and started by first full time job as an programmer. The theory of patterns taught me about the importance of names for concepts and the importance of communication with other developers. Five years later I went to a conference just to see Erich Gamma. Of course he spoke about patterns, but combined his talk with TDD, JUnit and a comparison of Java and C#. The lecture was not very long but brilliant. That was the first time I heard about TDD and got test infected.

Martin Fowler Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)

I read the book, when I already worked on enterprise applications for several years. The book was an revelation. Most of the problems described there I know very well, but now I got names for them and so many alternative solutions. This book gave me the possibility to better reflect about design and architecture decisions. This book was partly responsible that I became the architect of our project.

Martin Fowler, Kent Beck, John Brant, and William Opdyke Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)

Beside the refactorings and the theory, this book helped me so much to convince my team members of the benefits of TDD.

Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software

Brilliant book! The concept of the 'ubiquitous language' helped me very much for my day to day work. Using the 'Layered Architecture' pattern to separate technical details from the business concepts helped to better organize our software components.

Bertrand Meyer Object-Oriented Software Construction (Book/CD-ROM) (2nd Edition) (Prentice-Hall International Series in Computer Science)

Maybe this is the oldest book in my collection. Nevertheless it is still useful for me. I use assertions and 'programming by contract' nearly every day. This concepts can be used together with TDD very well. Even if you do not use Eiffel as the programming language, you can implement an assertion class for every other programming language in several minutes.

Mary Poppendieck and Tom Poppendieck Lean Software Development: An Agile Toolkit (Agile Software Development Series)

I never believed that other industries can teach the software industry about new concepts. After reading this book I know that the people from Toyota were very clever and the software people can learn a lot from them. Now I always try to find some 'waste' in our processes.

Kent Beck Extreme Programming Explained: Embrace Change (2nd Edition) (XP Series)

Although I never had the chance to work in a full blown XP project, this book is still a constant source of inspiration.

Kent Beck Test Driven Development: By Example (Addison-Wesley Signature Series)

If you start with TDD, read this book.

Gerard Meszaros xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series)

If you already worked a little bit with TDD, then read this book.

I'm very sure everyone has its own list. I would be glad to here from other people about their favorite books.

Mail Attachments without files

2008-03-31T22:33:00.005+02:00

I just received a comment about an article I wrote for www.codeproject.com. The article describes how to create and send mails with attachments in C# (no rocket science :-). The attachments are created in-memory without any file system access by the use of a memory stream: http://www.codeproject.com/KB/IP/InMemoryMailAttachment.aspx

TDD for Beginners

2008-03-28T23:22:00.006+01:00

Recently a colleague of mine, which is a quite experienced programmer, wants to write his first code using TDD. It takes only minutes until he encountered the first obstacle. It seems that TDD is quite difficult for beginners. I will describe some of the problems and show code examples to help TDD beginners to become familiar faster with this excellent technique. Based on these kinds of experiences I described also a pattern called Own Library Interface which is applicable in the situation described below. My colleague needs to implement a background service, which monitors a database. The background service has to send notifications to one or more external receivers. He designed an EmailSender class, which can be initialized with all email related information like the smtp server, the sender and the receiver email addresses. Now he wants to write the SendToAll() method, which only needs some information for the receivers:

public void SendToAll(string subject, string details)

He has already poked around in the .NET framework and has found the SmtpClient class for easy sending of emails. He wants to use this class in his own EmailSender class. He knows that he first has to write a test, if he wants to follow the TDD principles, before he can begin with the implementation. He starts to implement the test method, which should verify the successful execution of the method:

[TestFixture]
public class EmailSenderFixture
{
  [Test]
  public void SendToAll()
  {
    // Setup
    EmailSender sender = new EmailSender();
    ...

    // Exercise
    sender.SendToAll("TestSubject","TestDetails");

    // Verify
    // ?
  }
}

How can he verify the outcome of the SendToAll method? One solution would be to let his own class send emails to an email account and then checking the correct behaviour of his class by retrieving the emails via POP3. This solution has some disadvantages:

The tests would be very slow.
The tests need special preconditions (context) to run (smtp server, email account).
The tests would not only cover the functionality of the class alone but also the .NET framework class SmtpClient. Framework classes do not need to be tested, because it can be assumed that they work correctly. (Event if they do not, we can't do anything about that)
The retrieval of emails via the POP3 protocol has to be implemented only for the automated tests, which are currently not need for the production system.

I would always prefer to use state verification, that means verifying the outcome of a method by inspecting the state of the manipulated object, but in this case the class has no state which can be verified. As we have seen, the state verification of a backdoor (a real email account) has many drawbacks. An other solution would be the use of a mock object as a test double for the SmtpClient. Currently our SendToAll method is empty and uses no dependent object, which can be mocked out. My colleague decided to use mock objects to verify the behaviour of his class. He starts implementing an initial version of his method, before he finishes his test method. The initial version looks like this:

public class EmailSender
{
 private SmtpClient smtpClient;
 ...
 public EmailSender(
  SmtpClient smtpClient,
  string host,
  int port,
  string from,
  params string[] recipients)
 {
  this.smtpClient = smtpClient;
  this.from = from;
  this.port = port;
  this.host = host;
  this.recipients = recipients;
 }

 public void SendToAll(string subject, string details)
 {
  smtpClient.Host = host;
  smtpClient.Port = port;

  foreach (string recipient in recipients)
  {
      smtpClient.Send(
   from,
   recipient,
   subject,
   details);
  }
 }
}

He already injected the SmtpClient object via the constructor and uses this object to send the emails. This is a nice try but unfortunately he can't mock out the SmtpClient yet. The SmtpClient framework class does not inherit from any interface nor does it declare its methods as virtual, so he can't create a mock object for SmtpClient. This lack of 'mockability' is quite common for most of the classes in the Microsoft .NET framework. Cwalina and Abrams [1] are describing rules for the design of framework classes: "Class-based APIs can be evolved with much greater ease than interface-based APIs because it is possible to add members to a class without breaking existing code". From the perspective of framework designers it is absolute understandable, that most of the classes do not use interfaces. As unit test authors we have to write our own interfaces which mirror the API of the framework classes as close as possible and later write very thin wrappers inheriting from our interface. My colleague only uses two properties and one method of the SmtpClient class. He only needs to declare these members in his new interface:

public interface ISmtpClient
{
 string Host { get; set; }
 int Port { get; set; }
 void Send(string from, string recipients,
      string subject, string body);
}

Now he can slightly modify his EmailSender class to use the ISmtpClient interface instead of SmtpClient framework class directly:

public class EmailSender
{
 private ISmtpClient smtpClient;
 ...
 public EmailSender(
  ISmtpClient smtpClient,
  string host,
  int port,
  string from,
  params string[] recipients)
 {
  this.smtpClient = smtpClient;
  ...
 }
 ...
}

He finishes his test and verifies the behaviour of the EmailSender class. He is using the NMock2 framework for his mock object:

using NMock2;
...
[Test]
public void SendToAll()
{
 // Setup
 Mockery mocks = new Mockery();
 ISmtpClient smtpClientMock = mocks.NewMock<ISmtpClient>();

 EmailSender sender = new EmailSender(
  smtpClientMock,
  "smtp.test.com",
  25,
  "sender@test.com",
  "receiver1@test.com",
  "receiver2@test.com");

 Expect.Once.On(smtpClientMock).
  SetProperty("Host").
  To("smtp.test.com");
  Expect.Once.On(smtpClientMock).
  SetProperty("Port").To(25);

 // We expect that the Send method is called for every recipient
 Expect.Once.On(smtpClientMock).Method("Send").
  With("sender@test.com", "receiver1@test.com",
       "TestSubject", "TestDetails");
  Expect.Once.On(smtpClientMock).Method("Send").
  With("sender@test.com", "receiver2@test.com",
       "TestSubject", "TestDetails");

 // Exercise
 sender.SendToAll("TestSubject", "TestDetails");

 // Verify
 mocks.VerifyAllExpectationsHaveBeenMet();
}

This test runs very fast and it does not need any special context like an smtp server or an email account. Before he can use the EmailSender class in a production environment he has to implement a thin wrapper around the SmtpClient framework class:

public class SmtpClientWrapper : ISmtpClient
{
 private SmtpClient smtpClient = new SmtpClient();

 public string Host
 {
  get { return smtpClient.Host; }
  set { smtpClient.Host = value; }
 }

 public int Port
 {
  get { return smtpClient.Port; }
  set { smtpClient.Port = value; }
 }

 public void Send(string from,
  string recipients,
  string subject,
  string body)
 {
  smtpClient.Send(from, recipients, subject, body);
 }
}

This wrapper needs not to be tested, because it adds no new functionality to the framework class. The EmailSender class can now be used in the background service:

public void Run()
{
 EmailSender sender = new EmailSender(
  new SmtpClientWrapper(),
  "smtpserver.xy.com",
  25,
  "sender@xy.com",
  "receiver1@xy.com",
  "receiver2@xy.com");

 while (!stopped)
 {
  // Check something
  string checkResult = Check();

  // Send email
  sender.SendToAll("Check", checkResult);

  // Sleep for 20 minutes
  Thread.Sleep(20*60*1000);
 }
}

Conclusion

Applying TDD as a new technique for software development is sometimes not easy for beginners. When we need to write software, which has to use framework classes, we need to use mock objects and we eventually have to introduce new interfaces and wrappers. The same problems we saw with SmtpClient arise when we have to use classes like System.ServiceProcess.ServiceController, System.Diagnostics.EventLog, System.DirectoryServices.ActiveDirectory.Domain, System.Net.NetworkInformation.NetworkInterface, System.Net.Sockets.Socket, System.Environment, Microsoft.Win32.Registry just to name a few. I hope this article can help a little bit to overcome the first hurdles when using TDD the first time.

References

[1] Cwalina, K., Abrams, B.: Framework Design Guidelines, Microsoft .NET Development Series, Addison Wesley, 2006