Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv6151/doc/xdocs
Added Files:
introduction.xml
Log Message:
Moved from html version
--- NEW FILE: introduction.xml ---
<part>
<title>Introducing Test-Driven Development</title>
<chapter><title>Introduction</title>
<section>
<title>Why I wrote this book</title>
<para>
My original motivation for this book was that I got tired of
explaining what a group of us in London were doing with test-driven
development. We had discovered a style of programming that delivered
well-structured, reliable code quickly and that seemed to reinforce
what we had learned over the years to be good coding habits. Over and
over again, we found that developers thought that what we were doing
was unnecessary, or too complicated, or too hard to understand, or
just weird until we sat down and programmed through some examples with
them. This seemed like a very slow way to spread a useful idea, so I
started writing to try to speed things up.
</para>
<para>
Since then, I have had my motivation strengthened by the experience
of taking over development of a couple of systems written
elsewhere. Both systems worked and were developed under time pressure,
so clearly the programmers had got something right. Both systems,
however, were brittle, with much repetition and needlessly complex
logic. One, in particular, had accrued over years and noone had had
the time or, perhaps, the inclination to clean up behind
themselves. Worse, there were no automated tests (of course, the
documentation was out of date) so I could only make changes to the
working system by being very cautious and, where possible,
retrofitting tests. The contrast with the experience of raw confidence
when working with a fully test-driven codebase was so unpleasant that
I resolved to do <emphasis>something</emphasis>, however small, to improve the
situation.
</para>
<para>
My intentions are entirely selfish, I want to increase the
probability by a notch that the next system I have to deal with has
been written test-first so that I don't have to do this again. I have
an unselfish intention as well, which is that no-one in the next
generation of programmers should have to go through the Debug Hell
that we old fogeys accept as part of the process of writing software.
It <emphasis>is</emphasis> possible to fall off the rails with Test-Driven
Development, but it's so rare that we would have to make an effort to
preserve the skills when Test-Driven Development becomes the standard
way to write code.
</para>
</section>
<section>
<title>Who this book is for</title>
<para>
As with most authors, I'm writing this book for people like me who
happen not have seen some of the same things. It's for working
programmers who want to learn more about how to do Test-Driven
Development in practice. I'm assuming that:
</para>
<itemizedlist spacing="compact">
<listitem><para>
you already think that Test-Driven Development is a good idea, or
at least worth investigating;
</para></listitem>
<listitem><para>
you know something about the basics, such as refactoring and the JUnit framework; and,
</para></listitem>
<listitem><para>
if you're not currently working in Java, then you can figure out how to apply these concepts
to whatever environment you're working in.
</para></listitem>
</itemizedlist>
</section>
<section><title>Organisation</title></section>
</chapter>
<chapter><title>Test-Driven Development</title>
<section><title>Introduction and simple example</title></section>
<section><title>A quick tour of JUnit</title> </section>
</chapter>
&chp_how_mocks_happened;
<chapter><title>Expectations</title>
</chapter>
</part>
|
