Agile Attitudes- Beyond Unit Testing

[agileattitudes at agilerules.com]

Agile Attitudes
Volume 1, Issue 13                                     Dec. 2, 2004
         A free bi-weekly email newsletter
                Brought to you by
             Agile Rules consulting
               www.agilerules.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Welcome to Agile Attitudes, a newsletter of ideas, insights and
technical tips that help people find better ways to develop
software. Feel free to share this with anyone - just be sure you
send or print the whole thing, including the copyright notice.

Directions for managing your subscription are below.

                 O><O><O><O><O><O

Bad news!! The Dec 9 Agile Bazaar meeting hosting Alistair Cockburn
had to be canceled. We are deeply sorry if this has caused any
inconvenience.

                 O><O><O><O><O><O

               Beyond Unit Testing
                 by Ron Morsicato


I recently read a rather scathing criticism of an agile view-
point where the main point was that agile methodologies have
too much of an emphasis on unit testing. In the author's mind,
by focusing on unit tests, developers are spending an inordinate
amount of time cleaning up the simplest of defects, and ignoring
the more difficult to detect defects that have to to with the
proper collaboration of domains (those collections of units
that provide sets of services for other components of the system
being built).

I do not deny that domain-level and system-level integration
testing is important. I wonder why it follows that if you make the
effort to ensure each unit has a test, that higher level testing
is ignored. I also wonder why the critic believes that good unit
tests won't also produce a well-designed system with well-designed
domains.

When you use test-driven development, you benefit not only from
test coverage at the unit level, but also from side effects of a
development pattern that leads to better code. The pattern is
quite simple - fail, pass, refactor. This sounds strange: is a
developer to write bad code first? Of course not; you see the
reason you fail is that you write the test first. You test for
functionality that doesn't exist yet. (And now you know you will
detect a failure.) Then you put in the functionality. You put it
in the unit you wrote the test for. But there's another step -
and this is the important one - you refactor. (There's that word
again.) This is where you ask questions like whether there is a
simpler way to achieve this functionality, or if there some coding
pattern that's repeating itself, and how to get it in one place.

When you make the refactoring a reality, that's when you reap
benefits that go beyond simply having an all-inclusive unit
test suite. In addition to eliminating duplication, this approach
will simplify your architecture by eliminating circular reasoning
when it comes to the interdependency of your system components.
In other words, it makes those domains truly independent of each
other, and will cut down on those domain level defects. That's
an overlooked benefit of emphasizing unit testing (using the
fail, pass, refactor pattern), and is key to why test driven
development produces better code.


                 O><O><O><O><O><O
More articles on Agile software topics at http://www.agilerules.com
Within our company we have a sub-specialty in embedded systems.
Our site has articles on embedded XP and we support a discussion
list focused on the use of agile methods for building embedded
software. The list signup info is at
http://www.agilerules.com/mailinglists.phtml

                 O><O><O><O><O><O
To help you get started with in-depth research into Agile Attitudes
topics, we have added a Library section to our web site at
http://www.agilerules.com/library.phtml
Order using our links and receive discounts up to 30%!

                 O><O><O><O><O><O
If you enjoyed this issue or found it useful, forward it to a
friend! Help spread the word about better ways to build software.
Invite your friends and colleagues to join our growing reader
community at http://www.agilerules.com/mailinglists.phtml

                 O><O><O><O><O><O
Looking for a speaker for your next corporate or society meeting?
We present dynamic, informative programs on topics of interest
to managers and technical staff in their transition to more
flexible, robust ways to create software.

                 O><O><O><O><O><O
Want to reprint this issue in your company or society newsletter?
For permission to reprint any of the articles, contact us at
info at agilerules.com.

                 O><O><O><O><O><O

If you would like to receive an email as soon as we know of
an event in the Boston area of interest to the agile software
community, you can sign up for the announcements list at
http://www.agilerules.com/mailman/listinfo/agileannounce

                 O><O><O><O><O><O

Your feedback is welcome! Send feedback to info at agilerules.com

To manage your subscription:
http://www.agilerules.com/mailman/listinfo/agileattitudes

                 O><O><O><O><O><O
    Brought to you by Agile Rules consulting
      162 Marrett Road, Lexington MA 02421

         Copyright (c) 2004 Agile Rules
               info at agilerules.com

                 O><O><O><O><O><O
Privacy notice: We will not release a subscriber's address to any
third party for any reason. This is a strictly opt-in newsletter.
No one is ever subscribed without their explicit request.