Testing communication | 27
W
riting software that all to see and dispose of extraneous
‘does the right thing’ features. We can then use this to
is dependent on good continually help the customer decide
communication with what is the most important value and
the customer. We accept that our hence features for them.
understanding and our customers’
understanding of the ‘right thing’ is Having a definition of ‘done’
continually changing during the course of To deliver the right features we need
a project. So how can we help prevent this a target to hit. By getting a definition
communication gap from turning into a of ‘done’ from the customer we have a
chasm of despair? goal we can aim at. We also help avoid
the common “that is not what I asked
Getting the words right for” or “I forgot to tell you about this
Behaviour Driven Development other thing” comments.
(BDD) an evolution from Test Driven
Development (TDD) and Domain Having continuous feedback
Driven Development (DDD) (see side through User Acceptance Tests
bar for an explanation of these terms) In order to know when we are done
can help us move towards a consistent and what we have left to do we want
way of expressing behaviour with the our definitions of done to act as
customer’s domain terminology. automated tests against our system.
What we want is a ubiquitous
language that spans the divide Plain text User Acceptance Tests
between the business and the By using plain-text we enable non-
While the customer may
technology in describing the behaviour technical users to write collaboratively
have a number of feature
of a system. The business vocabulary with developers/business about the
permeates right into the tests and interesting behaviour of a feature using
requests it may not always
code base. Building the ubiquitous their ‘own words’. Our definitions of
be apparent exactly why
language is a balance between the behaviour, given as scenarios, are made
the customer wants a
customer’s domain and the software executable as tests through developers
feature. From discussions
team’s understanding, ultimately mapping the plain text to test code.
converging on a shared model. If we Using these tests in a continuous
and driving questions
can sit down with the client and talk integration server you can achieve
about why a feature is
about the interesting behaviour of constant feedback on your progress required we can help
their system we have a good start towards ‘done’. You retrospectively
extract the business value
at ensuring we converge on the know that changes to the system do
right solution. not break pre-existing features.
for all to see and dispose
Tools such as Fitnesse take a website
of extraneous features.
Driving out the business value wiki-style approach to allow plain text We can then use this
While the customer may have a tests. Through a browser you can edit
to continually help the
number of feature requests it may webpages which contain the plain
customer decide what
not always be apparent exactly why text of your test. One up-and-coming
the customer wants a feature. From framework called Cucumber expands
is the most important
discussions and driving questions on some of the ideas of Fitnesse while value and hence features
about why a feature is required we using a style of plain text user story to
for them.
can help extract the business value for capture system behaviour.
T.E.S.T | March 09 March 09 | T.E.S.T
Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52