PlanetHurley.com

Quite a few of our my development teams' products have adopted Test-Driven Development (TDD) with the planning driven by User Stories.

For those who are not familiar with user stories, they describe every expected behaviour of a system.

What our user-stories today have lacked, is a standard in their format and identification of all their acceptance criteria.

Stating the acceptance criteria is critical, as how else do we know our system actually has the correct behaviour?

One way in which we can achieve this, is by following the Given-When-Then (GWT) concept.

"GIVEN an employee named Arnold making £100 per hour. WHEN Arnold works 40 hours in one week; THEN Arnold will be paid £480 on Friday evening."

This concept helps describe expected behaviour, along with the associated acceptance criteria. This could directly translate into a unit test as shown (using NUnit and AAA (Arrange/Act/Assert) syntax)...

       [Test]
	public void FridayEveningPay()
	{
		// Arrange
		var poundsPerHour = 100;
		var arnold = new Employee(poundsPerHour);

		// Act
		arnold.Works(40);

		// Assert
		Assert.That(arnold.PayDay, Is.EqualTo(DayOfWeek.Friday), "Pay Day");
		Assert.That(arnold.PayDue, Is.EqualTo(4000), "Pay Due");
	}

By following Test-Driven development you only write enough code to meet the user-story's acceptance criteria. Please see below the 3 laws of TDD for your info:

• Don't write a line of production code until you have a failing unit test Don't write more of a unit test than is sufficient to fail
• Don't write more production code than is sufficient to pass the failing test

If anyone fancies chatting about the GWT concept, then give me a shout as I feel it can make a positive affect to our planning, development and testing stages. Resulting in:

• A more thoughtout end-product Another step to prevent developer over-engineering
• Improved efficiency of planning
• Reduced testing time
• Reduced overall time of project, based on all above
• More trust in a release of a product