Driving on the Right Side of the Code

The other day I was discussing with software testing expert Antony Marcano about the issues encountered in introducing Test driven development in a team. Especially we were talking about resistance from the developers in introducing automated acceptance testing.

They see them as redundant: they implemented the feature and they know it works, so why do they have to write additional tests?

I reckon what has not been perceived by the developers in such situation is:
For one, a developed feature will have a life after its first release, it often has to stay part of the product for a long time. Sometimes the feature will be improved or changed as driven by clients requirements (more on that later). During all that time the client need to be sure that the feature is working. It's obvious why the fact that the developer knows it's working at one point in time is not enough.
Even if the feature is not being change for a long period, there may be other features that are added or changed that may break that stable feature because of interdependencies.

Secondly, what has been completely missed is the fact that an acceptance test in TDD is not really a "test" in the meaning that is commonly understood by developers.
this look like a language barriers issue (This is where Antony mentioned to me the existence of behavior driven development - or BDD). Acceptance tests are to represents the specification for a feature defined by the customer/business owner.
This specification takes the form of an automated test so that developers can code the feature against it. From a developer's perspective it is a tangible goal to work against. Before the feature is created the test fails, when it's done the test is passing. The acceptance tests "drive" developers effort.

This way of expressing requirements reduces the risk of ever-changing requirements as the business owner would have to update the acceptance test each time making him/her think twice when creating/changing the specification for a feature. That's a win for the developers.
Because the business owner has written the test (maybe with help of a tester), when the test passes , they know that the feature that has been developed is what they wanted and it's working. That's a win for business owner.
The business owner and the developer know that at whatever stage of the life of a product, there is an automated test to assert that a particular feature is working. That's a win for both.

On the same subject, The Register has published an excellent article last night:

_Driving on the Right Side of the Code: "

Test Driven Development

Column Perhaps one of the most interesting things about TDD is not the specification-oriented and design-centred role in which testing is employed, but the amount of explanation it requires as a term. And I don't just mean expanding the abbreviation to Test-Driven Development or Test-Driven Design, as opposed to, say, Telecommunications Device for the Deaf (That said, I have heard it mistaken for Top-Down Design.)…


(Via The Register.)