testingReflections.com - test driven development

"From here to Acceptance Test Driven Development"

Sat, 13 Sep 2008 04:48:08 -0500

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.

The Telephone Game...

Sat, 13 Sep 2008 04:28:14 -0500

In an earlier post, I mentioned Boehm's distinction between 'verification' and 'validation':

Verification - Am I building the product RIGHT?

Validation - Am I building the RIGHT product?

-Boehm, Software Engineering Economics

As I was writing an article to appear in the September 2008 issue of Better Software Magazine I arrived at a better way of getting my point across...

A test is "an example of the rule in practice", but...

Wed, 06 Aug 2008 17:23:49 -0500

In Jason Gorman's post called Tests Are Instances Of Rules he says:

In test-driven development, we use tests as executable specifications of what is required of the software we create.

For this to work effectively, our tests have to convey the underlying intent. And this requires us to ponder the relationship between a test and a specification.

If only software development was like listening to internet radio...

Thu, 24 Apr 2008 12:46:28 -0500

It's true - people who don't get TDD hear the word 'Test' and all but ignore the 'Driven Development' part of it... sometimes to the point that they assume "oh, that's that testers job then"... or the opposite happens when you hear "doesn't that mean developers spend time testing when they should be writing code?"... It can take long and hard to break through this initial cultural barrier... For a long time I've searched for a way other than dropping the word 'T' in 'TDD' to break through the inevitable barrier and I'd almost given up hope... to the point where I was about to resort to the BDD philosophy. The benefits of test-infection made me persist.

To try to get people to understand the 'Driven Development' aspect of writing customer tests first a.k.a. "Acceptance Test Driven Development" (ATDD) and the relevance of the test and testing and testers and let's not forget early and frequent customer feedback... I've been using a different approach. It doesn't solve all of the problems caused by the letter 'T' but it does solve one of them - the part where people ignore the fact that the tests are driving development (yes I said 'tests' not 'testers' - I emphasise this because someone recently asked me 'so, how exactly do the testers drive the developers?').

So... let's talk about something else for a second... I want you to stop thinking about testing... for one moment. I want you to forget about the word 'test' and all the connotations that go along with it... I want you to think about something else... something random... let's say... 'Internet Radio'...

Discovery vs. Confirmation

Sat, 29 Mar 2008 01:44:58 -0500

When I hear debates about scripted vs. exploratory testing... or even debates such as "automate all tests" vs. "you can't automate all tests"... I don't think I'm hearing the real debate.

I think the debate that I'm hearing is "testing is about confirmation" vs. "testing is about discovery".

This distinction in the underlying intent of a given approach seems to not be emphasised in these discussions.

In simple terms, I think of the intent behind testing as having two facets:

Confirmation - Does the system do what we anticipated it should do?
Discovery - Does the system do (or not do) anything we did not anticipate it would (or should do)?

Losing the "T" in TDD - what do you lose vs. what do you gain?

Mon, 31 Mar 2008 04:53:07 -0500

In a recent post from Jason Gorman he discusses how some people drop the word 'Test' from Test-Driven Development.

I feel their pain... I've felt that way in the past but eventually changed my mind...

Jason explains emphasis of 'Test-Driven Development':

The problem with Test-driven Development is that it's got the word "test" in the title. It's actually not as much about tetsing your code as it is about using tests to specify what code you should write in the first place.

What is it like to be a...

Sun, 23 Mar 2008 06:30:11 -0500

A while back, a colleague - Tim Smith - pointed me at Thomas Nagel's collection of philosophical essays in the book "Mortal Questions".

I was captivated by Nagel's seminal essay "What is it like to be a bat?"

Nagel’s essay discusses perception and poses a strong argument that there is no such thing as objectivity. I.e. we may distil a bat’s system of vision into the concept of Sonar but we can’t possibly know how the bat experiences it because we have only our perception of visible-light, our separate perception of audible sounds and the metaphor of a submarine's sonar to compare it to.

Performance testing - still in the post-hoc ghetto of a test-driven world?

Mon, 17 Mar 2008 05:11:45 -0500

As some of you may recall, a couple of years ago I ran a workshop on Agile Performance testing.

You can find out more about this by searching for WOPR7.

The general theme, with the exception of one experience report, focused on post-hoc performance testing. A lot of work has been done over the last decade to advance functional test-driven development. When I say 'functional' I don't mean 'application level tests' (a.k.a. acceptance tests); I mean tests at the level of unit, acceptance and every level in between where these tests are concerned with functional behaviours (of the unit or the application respectively).

Generalising Specifications vs. Specification by Example - Verification vs. Validation

Sun, 02 Mar 2008 03:57:43 -0600

Specification by example is the concept underlying TDD (in all its forms). In essence, each test is an expression of an example of how a system (in the case of acceptance tests) or component (in the case of unit tests) will be used.

If you want to know why TDD is often described as a form of "specification by example" one of the best analogies is Jason Gorman's Kitchen (I know - strange that he has deviated from golf for a change).

Something I've noticed in the TDD discussions on the web is that the phrase "formal specification" is used to label other more typical techniques of specification. Formal specification has a specific meaning of course, but I'm not sure it is a fair term as I consider the application of "specification by example" in the form of TDD and Acceptance-Test-Driven Development as being very formal.

Why don't you just tell me?

Fri, 20 Jul 2007 01:55:01 -0500

[textile]At STAREast 2007, "James Bach":http://satisfice.com/blog/ told a story of a project he once worked on. The project's methodology was somewhat traditional, in the sense that developers wrote code and testers then performed "inspective testing":http://www.testingreflections.com/node/view/5605 of the application. James found numerous bugs, reporting them back. This seemed to cause the programmer some frustration. James told of the programmer complaining... "why don't you just tell me what tests you're going to do and I'll make sure that the code passes them before I give it to you?"

I liked the story... I now use it to explain something to the teams I work with.

After telling the story, I ask "What if we could tell the developer what tests we're going to do in advance"?

AgitarOne - generating JUnit Tests... but there is a price to pay...

Wed, 29 Nov 2006 16:07:46 -0600

[textile]About 9 months ago, I spent some time with one of the guys from Agitar, looking at their Agitator product. I held back from recommending it to a client because the client was just getting to grips with Test Driven Development.

"If only you could use it to turn its observations into JUnit Tests. What a great way to plug any gaps you might have left in your own tests!?!?!?" I thought. I envisaged the team writing their code Test-Driven and then using Agitator to plug any gaps they might have left.

Test Driven? Driven Tester? The role of a tester (on a Test Driven Project)

Thu, 29 Jun 2006 02:19:22 -0500

[textile]In Test-Driven Development By Example By Kent Beck, he says

However, if the defect density of test-driven code is low enough, then the role of professional testing will inevitably change from "adult supervision" to something more closely resembling an amplifier for the communication between those who generally have a feeling for what the system should do and those who will make it do.

This has definitely been my experience (although I find testers also serve many other roles critical to success, including a little "adult supervision" as he puts it). This generally occurs in two main ways in each (short) iteration of the projects I work on:

To obtain good code, writing tests and code is faster then code alone

Tue, 20 Jun 2006 08:01:10 -0500

A few weeks ago on the TestDrivenDevelopment mailing list, Ron Jeffies, one of the XP gurus, stated that "in order to obtain good code, writing tests and code is faster then just code". To find out if this is true or not let's make a small experiment here.

If a mock isn't a mock.... (I mock thee not)

Sun, 18 Jun 2006 17:10:28 -0500

[textile]The term "mock" gets thrown around a lot and different people seem to mean different things by it. I often ask "when you say mock object, what do you mean?" The reason I do that is because it seems that often (but not always), people use the term "mock" synonymously with anything that is not a real implementation of an object that collaborates with an object under test. This isn't entirely accurate...

"Mock Objects is a test-first development process for building object-oriented software"

from - "http://www.mockobjects.com/FrontPage.html":http://www.mockobjects.com/FrontPage.html The mock objects used in the process are defined as...

Integrating Unit Testing Into A Software Development Teams Process

Thu, 16 Feb 2006 03:04:59 -0600

Unit testing was integrated into the software development process of a five-member programming team using a test-during-coding training module. The training approach and module are briefly described. Individual and pair developer performance was measured before and after the training module was presented. The improvements inquality achieved by the team ranged from 38% to 267% fewer defects.