Ayyanar Aswathaman wrote:
In the traditional development method like waterfal approach, we create
the requirement and design document. The code will be done after
requirement and design. Unit test will be written to test the existing
code block.
If at all!
I understand that rspecs will act as the requirement and design document
in BDD. We can also write test case using rpsec.
I believe, we can create the plain text stories in rspec first. After
coding we can write the test case for the expected behaviour. How
the text stories and test cases are connected? How we will make sure
all the expected behaviours in the text stories are met?
You are asking how “Agile” development works. Unfortunately, if you
google for
that, you will find a lot of noise, enthusiastic discussion, and
advocacy. Agile
is so popular that it’s hard to get the idea what Agile “is” these days!
At my day job, we have two or three “pair stations”. That’s a
workstation with
two monitors, two keyboards, two mice, and two chairs. We do our
important work
- typically cutting new code - in pairs. Whoever thinks of something to
type
describes it to the other, and they type it in.
We alternate between writing tests and writing code, in very small
cycles. We do
this:
http://c2.com/cgi/wiki?TestDrivenDevelopment
That means if you think of a new line of code to write, you first write
a test
case that fails because it’s not there. Only when the test case is
failing for
the correct reason do you write a little code to pass the test.
To help us rapidly determine if a case is failing for the correct
reason, I
invented a new kind of assertion:
http://assert2.rubyforge.org/
Our tests also cover details in Views, so we use XPath to validate our
XHTML,
and to find details in it:
http://assertxpath.rubyforge.org/
(Get that one with ‘gem install assert_xpath’.)
Both work with RSpec.
When we edit, we hit one button in our editor (F5), and it saves all our
code.
Then we have a script that detects any changes, and runs every test
suite that
has been changed since the last integration. This means we can test very
frequently, after each edit. We predict, out loud, what the test run
will do. If
it fails unexpectedly, we have the option to Undo, or even ‘svn revert’,
to get
back to passing tests.
Undoing is much /much/ MUCH more productive than debugging!
As soon as we have improved our code, in any way, we integrate. That
means we
check out all changes, pass all our tests, and only ‘svn checkin’ if all
the
tests pass. These practices rigorously keep bugs out of our codebase.
We also deploy our code to live servers each time we add a new feature.
We have no “text stories” - only test cases. Our “onsite customer” keeps
text
lists of features by name, but they are only detailed enough for him.
Our managers have a weekly meeting where they ask our onsite customer
for more
features. These features are usually always tiny increments over our
current
code state. If we added a new page last month, for example, our workers
might
report they need a simplification on it, or more data in a corner, or
something.
Their manager petitions our manager, who writes the name of the feature
on a
card, then (within a week) tells us to do it.
A simple feature like a new button should take only a few hours, with
our
combination of Rails, clean code, and Test Driven Development. The
workers will
get the new feature that day.
We can absorb feature requests in any order, without scrambling our
code,
because we always take time after each feature requests to refactor the
code.
That means improve its design in tiny steps, while passing all tests
between
each step. To improve the design, we find code that is similar, and try
to make
it look exactly the same. Pass all tests. When it looks the same, we can
delete
one copy of the code, and then call into it from another call site. This
process
makes the code “DRY” - Don’t Repeat Yourself.
The tests then thoroughly document what our code does. To answer a
question
about behavior, we read all the names of the tests, and their contents.
We try
to make each case as “literate” as possible.
We can also analyze behavior by putting a ‘raise “yo”’ inside a suspect
method.
Then we run all the tests. The ones that fail will document that method!
These practices reduce bugs, and make our projects very easy for
managers to steer.
–
Phlip