This article provides an introduction to Test-Driven Development with concrete examples using Nunit.

we are faced with a double edged sword. First, there is no formal unit test engineering discipline established in the community that provides a guide to the programmer and works to ensure some level of unit test quality. Second, the prerequisite that the design has to be somewhat formalized before any tests can be written causes difficulty for many programmers because they either don't have formal design experience or simply don't like up front design work. Aggravating this situation is the idea that up front design work can be replaced under the guise of "refactoring". In order to blunt this sword, two things are needed--a formalization of unit testing by establishing unit test patterns, and the early adoption of object oriented design patterns in the developing application to specifically target the needs of unit testing.

Inversion of Control (IOC) is a new pattern that has been gaining popularity recently. The pattern is based on a few simple concepts that deliver a highly decoupled, lightweight, mobile, and unit-testable code base.

The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. However the term mock was not originally meant as a more catchy name for stub, but to introduce a different approach to unit testing. In this article I dig into this difference of style to explain the difference between the interaction-based testing style favored by mock object fans, and the more usual state-based testing style.

This paper is a forward-thinking look at the application of test-driven development within the XML processing space.

This articles examines ten different ways you can change your code to make it ready to be tested. By doing so, you will be creating a more loosely coupled, flexible and transparent architecture, which will benefit you not only in testing but in documentation, maintenance and, eventually, modification. With a little forethought and some careful implementation, the unit tests can drive more than the QA process; it can help you design a more robust application in the first place.

This article examines the whys and wherefores of continuous integration, and examines two of the leading (open source) tools for providing this service: Draco.NET and CruiseControl.NET. You will see how to get each up and running, and compare their strengths and weaknesses to determine when each is a better fit for your organization.

Continuous Integration is one of the buzzwords most people have probably heard of but surprisingly few are actually following this XP best practice. Keeping this in mind, I'll begin this tutorial by briefly describing what Continuous Integration actually means, why you should consider doing it, and finally, showing step by step how to do it using one of the most used Continuous Integration products, the open source CruiseControl.

In Part 1 of this tutorial, we set up the CruiseControl Continuous Integration server against a Subversion repository. In this second part, we'll continue where we left off by taking our build results online with the CruiseControl reporting web application.

This guide will show you how to setup J2MEUnit in a modern IDE like Eclipse and write your first test case. Once you have followed all the steps you will have a test-driven development environment ready to go.