I'm working with a customer that is implementing a website that allows customers to purchase products... This site has to talk to various webservices to obtain information about pricing and delivery options.

They were concerned that they didn't know what the interface for the delivery options web service was going to be so of course, I simply highlighted that this should be abstracted from their system as much as possible. All they new is that for a given order (made up of delivery address and the list of products) delivery options will vary depending on the types of products ordered and the delivery address. Other solutions (such as an internal call-centre package) will also be using the delivery options web service.

My Article "From here to Acceptance Test Driven Development - 9 Landmarks to find your way" has been published in Better Software Magazine... make sure you pick up a copy.

Acceptance test-driven development (ATDD) means many things to many people—from “It’s all about testing” to “It has nothing to do with testing,” and from “TDD, ATDD—it’s all the same” to “TDD and ATDD are nothing alike.” Each of these statements describes ATTD from a single perspective, but neither encapsulates the entire meaning. This is often because different people notice different aspects of ATDD depending on where they are coming from.

As I've mentioned before, in acceptance test driven development, I use the Given/When/Then structure for writing acceptance tests. This approach is attributed to Dan North and Joe Walnes presentation at XPDay 2006.

For example, let's consider a test for a story around logging in (I know - I always use this but it's something most people have experience of):

Firstly, my thanks to Gojko Adzic for giving such a rapid response on the FitNesse mailing list to help me solve the problem I encountered getting my .NET assemblies loaded in FitNesse .NET...

After at least 2 years of doing absolutely no .NET work, I started working with a .NET team this week, helping them to use FitNesse.

Trying to run my test for the first time, the FitServer.exe just wasn't finding my assembly... HelloFitNesse.dll

I'll be giving a free evening public talk in Clerkenwell, London for SkillsMatter on 8th September at 18:30pm. The talk is applicable to anyone on an agile team or running agile projects...

Testing is an integral and prominent aspect of agile development, however, new teams form and existing teams prevail with uncertainty about how testers fit into the process. Even those projects that don’t have testers dedicated to them can still feel there is a void in how they ensure that they are building the right product and building the product right.

Cross-functional teams are growing in popularity, influenced in no small part by the growth in adoption of agile values and the methodologies that support them.

Whether it's a side effect of getting developers and testers working more closely or due to the undulating skills demands from iteration to iteration, each team-member is increasingly expected to have more diverse skills. Furthermore, Test Driven Development increases the need for developers to know more about testing; automated acceptance tests as part of Acceptance Test Driven Development written in the same language as the product increases the need for testers to know about programming.

No, this isn't on the same topic as my previous post on Udi Dahan's interface naming style. But, I have taken inspiration from it as I've been trying to find a way to communicate a people issue.

In that post, I was illustrating a point that Udi had made about naming interfaces not based on what they are but what they do... based on their roles...

I've been pairing with Andy Palmer over this last week. I have to say it's been a lot of fun... and I think we've learned a lot from the experience. One of the things I learned from Andy this week was an innovative use of Hungarian notation for interfaces... Andy told me about Udi Dahan's presentation on intentions and interfaces (PDF)