Menu
▾
▴
[MO-java-dev] CVS: no-stone-unturned/doc/xdocs preface.xml,NONE,1.1 htmlbook.xsl,1.7,1.8 doc-book.xml,1.8,1.9 introduction.xml,1.1,1.2 testing_guis_1.xml,1.5,1.6 how_mocks_happened.xml,1.3,1.4 random.xml,1.4,1.5 htmlbook.css,1.6,1.7 extra_entities.xml,1.4,1.5
|
From: Steve F. <sm...@us...> - 2002-08-10 23:43:45
|
Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv25267/doc/xdocs
Modified Files:
htmlbook.xsl doc-book.xml introduction.xml testing_guis_1.xml
how_mocks_happened.xml random.xml htmlbook.css
extra_entities.xml
Added Files:
preface.xml
Log Message:
Restructuring
Rewriting within how_mocks_happened.
--- NEW FILE: preface.xml ---
<preface>
<title>Preface</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.
Of course, it <emphasis>is</emphasis> possible to fall off the rails with Test-Driven
Development, but it's a little bit harder. Our generation will know that we've really
succeeded when no-one can quite remember why we spent so much time building debugging
tools. I'm not holding my breath, but it's a target that's worth aspiring to.
</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 status="todo">
<title>Organisation</title>
&todo;
</section>
<section status="todo">
<title>Acknowledgements</title>
&todo;
</section>
</preface>
Index: htmlbook.xsl
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/htmlbook.xsl,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- htmlbook.xsl 10 Aug 2002 20:56:50 -0000 1.7
+++ htmlbook.xsl 10 Aug 2002 23:43:41 -0000 1.8
@@ -29,6 +29,22 @@
<xsl:call-template name="inline.gui"/>
</xsl:template>
+ <xsl:template name="inline.comment">
+ <xsl:param name="content">
+ <xsl:call-template name="anchor"/>
+ <xsl:call-template name="simple.xlink">
+ <xsl:with-param name="content">
+ <xsl:apply-templates/>
+ </xsl:with-param>
+ </xsl:call-template>
+ </xsl:param>
+ <span class="comment"><xsl:copy-of select="$content"/></span>
+ </xsl:template>
+
+ <xsl:template match="comment">
+ <xsl:call-template name="inline.comment"/>
+ </xsl:template>
+
<xsl:param name="generate.toc">
/book toc
/book/part toc
Index: doc-book.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/doc-book.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- doc-book.xml 10 Aug 2002 18:11:00 -0000 1.8
+++ doc-book.xml 10 Aug 2002 23:43:41 -0000 1.9
@@ -3,8 +3,10 @@
<!ENTITY % docbook SYSTEM "file://@docpath@/dtd/docbookx.dtd">
<!ENTITY % extra_entities SYSTEM "file://@docpath@/extra_entities.xml">
+ <!ENTITY preface SYSTEM "file://@docpath@/preface.xml">
+
<!ENTITY part_introduction SYSTEM "file://@docpath@/introduction.xml">
- <!ENTITY chp_how_mocks_happened SYSTEM "file://@docpath@/how_mocks_happened.xml">
+ <!ENTITY how_mocks_happened SYSTEM "file://@docpath@/how_mocks_happened.xml">
<!ENTITY chp_servlets_1 SYSTEM "file://@docpath@/servlets_1.xml">
<!ENTITY chp_servlets_2 SYSTEM "file://@docpath@/servlets_2.xml">
@@ -19,17 +21,15 @@
%extra_entities;
]>
-<book>
+<book status="draft">
<title>No Stone Unturned</title>
<bookinfo>
<author>
- <honorific>Dr</honorific>
<firstname>Steve</firstname> <surname>Freeman</surname>
<email>st...@m3...</email>
</author>
<author>
- <honorific>Dr</honorific>
<firstname>Nat</firstname> <surname>Pryce</surname>
<email>nat...@b1...</email>
</author>
@@ -39,45 +39,72 @@
</copyright>
</bookinfo>
- &part_introduction;
+ &preface;
- <part>
- <title>Larger examples</title>
+ &part_introduction;
+ <part status="draft">
+ <title>A longer example</title>
&chp_servlets_1;
&chp_servlets_2;
&chp_servlets_3;
+ </part>
+
+ <part status="draft">
+ <title>Working with third party libraries</title>
&chp_jdbc_testfirst;
</part>
&part_testing_guis;
- <part>
+ <part status="todo">
<title>Living with Unit Tests</title>
- <chapter><title>Test organisation</title></chapter>
- <chapter><title>Test smells</title></chapter>
- <chapter><title>Retrofitting unit tests</title></chapter>
+ <chapter status="todo">
+ <title>Test organisation</title>
+ &todo;
+ </chapter>
+ <chapter status="todo">
+ <title>Test smells</title>
+ &todo;
+ </chapter>
+ <chapter status="todo">
+ <title>Retrofitting unit tests</title>
+ &todo;
+ </chapter>
</part>
<part><title>Some other languages</title>
- <chapter><title>C++</title>
- <para>with Workshare?</para>
+ <chapter>
+ <title>C++</title>
+ &todo;
+ <comment><para>with Workshare?</para></comment>
</chapter>
- <chapter><title>Dynamic and metaprogramming</title></chapter>
- <chapter><title>bash</title></chapter>
+ <chapter>
+ <title>Dynamic and metaprogramming</title>
+ &todo;
+ </chapter>
+ <chapter>
+ <title>bash</title>
+ &todo;
+ </chapter>
</part>
<part>
- <title>Other patterns</title>
+ <title>Other cases</title>
&chp_random;
</part>
- <part>
+ <part status="todo">
<title>Closing</title>
+ &todo;
</part>
+ <appendix status="todo">
+ <title>The Expectation Library</title>
+ &todo;
+ </appendix>
¬es;
</book>
Index: introduction.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/introduction.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- introduction.xml 9 Aug 2002 23:47:43 -0000 1.1
+++ introduction.xml 10 Aug 2002 23:43:41 -0000 1.2
@@ -1,90 +1,31 @@
- <part>
- <title>Introducing Test-Driven Development</title>
+<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>
+ <preface status="draft">
+ <title>Preface</title>
+
+ <para>
+ In this part, we introduce Test-Driven Development. We only give a brief refresher on the basics, because there
+ are other books that are more suitable as an introduction to the technique. We do, however, spend some time
+ introducing Mock Objects because that's how a group of us have been developing for several years and we like
+ what it does to our code. Let's get down to business.
+ </para>
+ </preface>
+
+ <chapter status="todo">
+ <title>Test-Driven Development</title>
+
+ <section>
+ <title>Introduction and simple example</title>
+ &todo;
+ </section>
+ <section>
+ <title>A quick tour of JUnit</title>
+ &todo;
+ </section>
+ </chapter>
+
+ &how_mocks_happened;
+
+</part>
Index: testing_guis_1.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/testing_guis_1.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- testing_guis_1.xml 5 Aug 2002 01:30:48 -0000 1.5
+++ testing_guis_1.xml 10 Aug 2002 23:43:41 -0000 1.6
@@ -2,17 +2,18 @@
<title>Developing Graphical Applications</title>
<partintro>
+ <title>Introduction</title>
<para>
- It <emphasis>is</emphasis> possible to develop graphical applications test-first. It's not easy, because
- graphical user interfaces have to respond to people (who are less predictable and linear than we'd
- like) and so tend to have lots of global state that's hard to test in isolation. That, and the variable
- quality of some popular graphical toolkits, means that we have to think a bit harder we do for non-graphical
- applications. It took a while for the test-driven development community to figure out what to do, for a
- long time the answer was to make the presentation layer as thin as possible and to defer everything down
- to a business layer. That's probably why there are no tests for the graphical test runners for
- <application>JUnit</application>. This is still good advice but it doesn't feel good enough, given
- how much we say we believe in the benefits of writing the tests first. Now we have a better handle on how to
- work with graphical environments (or at least some of them). Let's see something working.
+ It <emphasis>is</emphasis> possible to develop graphical applications test-first. It's not easy, because
+ graphical user interfaces have to respond to people (who are less predictable and linear than we'd
+ like) and so tend to have lots of global state that's hard to test in isolation. That, and the variable
+ quality of some popular graphical toolkits, means that we have to think a bit harder we do for non-graphical
+ applications. It took a while for the test-driven development community to figure out what to do, for a
+ long time the answer was to make the presentation layer as thin as possible and to defer everything down
+ to a business layer. That's probably why there are no tests for the graphical test runners for
+ <application>JUnit</application>. This is still good advice but it doesn't feel good enough, given
+ how much we say we believe in the benefits of writing the tests first. Now we have a better handle on how to
+ work with graphical environments (or at least some of them). Let's see something working.
</para>
</partintro>
@@ -559,18 +560,17 @@
</para>
</sect1> <!-- What have we learned? -->
-
</chapter> <!-- Second test -->
+ <chapter status="todo">
+ <title>More test cases</title>
+ &todo;
+ </chapter>
+
<appendix id="findNamedComponent"
status="todo">
<title>Finding GUI components</title>
+ &todo;
</appendix>
- <appendix status="todo">
- <title>To do.</title>
- <simplelist type="vert">
- <member>redo GUI images on the same platform.</member>
- </simplelist>
- </appendix>
</part>
Index: how_mocks_happened.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/how_mocks_happened.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- how_mocks_happened.xml 10 Aug 2002 20:56:50 -0000 1.3
+++ how_mocks_happened.xml 10 Aug 2002 23:43:41 -0000 1.4
@@ -1,12 +1,13 @@
-<chapter>
+<chapter status="draft">
<title>How Mock Objects Happened</title>
<section>
<title>Introduction</title>
+
<para>
Mock Objects is a development technique that lets you unit test classes that you didn't think
- you could <emphasis>and</emphasis> helps you write better code whilst doing so. This chapter
- uses a simple example to show a compressed history of how Mock Objects was discovered by
+ you could <emphasis>and</emphasis> helps you write better code while doing so. In this chapter
+ we use a simple example to show a compressed history of how Mock Objects was discovered by
refactoring from conventional unit tests and why they're useful.
</para>
@@ -21,24 +22,23 @@
<section>
<title>Simple Unit Tests</title>
+ <para>Let's get straight into an example.</para>
+
<para>
- Let's dive straight into a worked example. We're writing software to direct robots through a
- warehouse. Given a starting point on a grid, it will find a route through the stacks to a
- specified destination. How can we test this? The standard approach is to write some unit tests
- that create a robot, call some methods on it, and then check that the resulting state is what we expect.
- Our tests will have to tell us, for example, that the robot arrives where it was directed to go and
- does not hit anything on the way. A easy test to start with is to check that a robot does not move
- if it is told to go to its current location:
+ We're writing software to direct a robot through a warehouse. Given a starting point on a grid, it will
+ find a route through the stacks to its destination. How can we test this? The standard approach
+ is to write some unit tests that create a robot, call some methods on it, and then check that it has
+ done what we asked. Our tests will have to tell us, for example, that the robot arrives
+ where it was directed to go and does not hit anything on the way. We'll start with the easiest test
+ we can think of, which is that the robot does not move if it is told to go to its current location:
</para>
<programlisting>
public class TestRobot {
- &elipsis;
- public void setUp() {
- robot = new Robot();
- }
public void testGotoSamePlace() {
final Position POSITION = new Position(1, 1);
+
+ Robot robot = new Robot();
robot.setCurrentPosition(POSITION);
robot.goTo(POSITION);
@@ -47,27 +47,36 @@
}</programlisting>
<para>
- This tells us that the robot thinks that it has arrived at the right place, but it doesn't tell us anything
- about how it got there; it might have trundled all the way round the warehouse before returning to
- its original location. We would like to know that the Robot hasn't moved. One option would
- be to store and retrieve the route it took after each <function>goto()</function>. For example:
+ This test tells us that the robot is in the same place after the test as it was before the test.
+ That's an essential requirement, but it's not enough. We can't be sure that the robot hasn't
+ trundled all the way around the warehouse before returning; we need to know that the Robot hasn't
+ moved. How about if the robot were to store the route it takes each time we call
+ <methodname>goto()</methodname>? We could retrieve the route and make sure it's valid. For example:
</para>
<programlisting>
public void testGotoSamePlace() {
final Position POSITION = new Position(0, 0);
+
+ Robot robot = new Robot();
robot.setCurrentPosition(POSITION);
robot.goTo(POSITION);
- assertEquals("Should be empty", 0, robot.getRecentMoveRequests().size());
+ <emphasis>assertEquals("Should be empty", 0, robot.getRecentMoveRequests().size());</emphasis>
assertEquals("Should be same", POSITION, robot.getPosition());
}</programlisting>
- <para>The test might be to move one point on the grid:</para>
+ <para>
+ So far we've specified that the Robot will not move if asked to go to the same place. We've
+ also specified that it will store the route from it's most recent move, and something about
+ the programming interface that it should support. Our next test is to move one point on the grid:
+ </para>
<programlisting>
public void testMoveOnePoint() {
final Position DESTINATION = new Position(1, 0);
+
+ Robot robot = new Robot();
robot.setCurrentPosition(new Position(0, 0));
robot.goto(DESTINATION);
@@ -79,13 +88,16 @@
}</programlisting>
<para>
- As the tests become more complex, we pull some of the detail out into helper methods to make
- the code more legible:
+ Now we've also specified the simplest routing scheme, for moves to adjacent squares, and that we're
+ describing each leg of the route with a <classname>MoveRequest</classname> object. We carry on and
+ pretty soon we're moving the Robot all over the building, for example:
</para>
<programlisting>
public void testMoveALongWay() {
final Position DESTINATION = new Position(34, 71);
+
+ Robot robot = new Robot();
robot.setCurrentPosition(new Position(0, 0));
robot.goto(DESTINATION);
@@ -95,45 +107,85 @@
}</programlisting>
<para>
- where <function>makeExpectedLongWayMoves()</function> returns a list of the
- moves we expect the robot to make for this test.
+ As the tests have become more complex, we've pulled out some of the detail into helper methods
+ to keep the tests legible. For example, <methodname>makeExpectedLongWayMoves()</methodname> returns
+ a list of the moves we expect the robot to make for this destination.
</para>
+ <sidebar>
+ <para>
+ Of course, you've noticed that we haven't said anything about the layout of the warehouse. We'll
+ assume for now that it's regular and hard-coded into the Robot.
+ </para>
+ </sidebar>
+
<para>
- There are problems with this approach to testing. First, tests like this are effectively
+ There are difficulties with this approach to testing. First, tests like this are effectively
small-scale integration tests, they set up pre-conditions and test post-conditions but they have no
- access to the code while it is running. If one of these tests fail, we will have to step through the
- code to find the problem because the assertions have been made <emphasis>after</emphasis> the call has finished.
+ access to the code while it is running. If this test failed, the error report would say something like:
+ </para>
+
+ <screen>
+There was 1 failure:
+1) testMoveALongWay(test.nostone.RobotTest)junit.framework.AssertionFailedError:
+ Should be same moves:<[10, South; 3, East; 7, South; &elipsis;> but was: <[10, South; 3, East; 7, South; &elipsis;>
+ at test.notstone.RobotTest.testMoveALongWay()
+FAILURES!!!</screen>
+
+ <para>
+ We will have to step through the code to find the problem because the assertions have
+ been made <emphasis>after</emphasis> the call has finished. Even so, the robot is a relatively simple example.
+ Some of us tried to do this with financial mathematics and it's very painful when a calculation fails.
+ A test failure usually meant stepping carefully through the code with an open spreadsheet nearby to check
+ the values.
+ </para>
+
+ <para>
Second, to test this behaviour at all, we had to add some functionality to the real code,
- to hold all the <classname>MoveRequest</classname>s since the last <function>goto()</function>.
- We don't have any other immediate need for <function>getRecentMovesRequests()</function>.
+ to hold all the <classname>MoveRequest</classname>s since the last <methodname>goto()</methodname>.
+ We don't have any other immediate need for <methodname>getRecentMovesRequests()</methodname> and,
+ what's worse, we've made an implicit promise to other people who work with the Robot code that we
+ will store routes, thus shrinking (ever so slightly) our room to manouver. We can mark the method as
+ test infrastructure, but that's messy and does tend to get ignored when in the heat of development.
+ </para>
+
+ <para>
Third, although it's not the case here, test suites based on extracting history from objects tend
to need lots of utilities for constructing and comparing collections of values. The need to write
- external code to manipulate an object is often a warning that its class is incomplete and that some
- behaviour should be moved from the utility to the class.
+ external code to manipulate an object is often a warning that its class is getting too busy and
+ that some behaviour should be moved from the utility to the class.
</para>
<para>
- Is there a better way? Can we find a style that will give me better error reporting and put the
- behaviour in the right place?
+ Is there a better way? Can we find a technique that's less intrusive, that doesn't require the Robot
+ to hang on to unnecessary values? Can we have more helpful testfailures—that will fail faster,
+ like we know we're supposed to? What would happen if we really believed in the object design
+ maxim <quote>Tell, don't ask</quote>?
</para>
</section> <!-- Simple Unit Tests -->
<section>
- <title>Factoring Out The Motor</title>
+ <title>Breaking the Robot apart</title>
+
+ <para>
+ Let's stop and think for a moment. Our robot is actually doing two things when we ask it to move
+ through the warehouse; it has to choose a route from its current position to its destination,
+ <emphasis>and</emphasis> it has to move along the route it has chosen. Those activities are
+ separate, even if they might happen at the same time. If we break out these responsibilities into two
+ objects, we can also separate the testing that goes with them. We can test that the route planning
+ object creates a suitable route and that the object that moves the Robot follows that route correctly.
+ We'll start with the "Robot Moving Object", what would be a good name for such a component? How about
+ <emphasis>Motor</emphasis>? If we leave the route planning in the <classname>Robot</classname> object,
+ we can intercept the requests that the <classname>Robot</classname> makes to its
+ <classname>Motor</classname>, which means that we can see inside without holding on to the route data.
+ </para>
<para>
- Our robot is actually doing two things when we ask it to move through the warehouse. It has to choose a
- route from its current position to where it has to go, and it has to move along the route it has chosen.
- If we separate these responsibilities into two objects, we break out the tests that go with them:
- that the route planning object creates a suitable route and that the robot moving object follows that
- route correctly. What's a good name for a robot moving object? How about <emphasis>Motor</emphasis>?
- If we leave the route planning in the <classname>Robot</classname> object, we can intercept the
- requests between the <classname>Robot</classname> and its <classname>Motor</classname> to see what's
- happening inside. We'll start by defining an interface for <classname>Motor</classname>. We know that
- there must be some kind of request, which we'll call <function>move()</function>, that takes a
- move request as a parameter. We don't yet know what's in that request, so we'll define an empty
- <classname>MoveRequest</classname> interface as a placeholder to get us through the compiler.
+ We'll start by defining an interface for <classname>Motor</classname>. We know that
+ there must be some kind of request, which we'll call <methodname>move()</methodname>, that takes some
+ kind of move request as a parameter. We don't yet know what's in that request, so we'll define an empty
+ <classname>MoveRequest</classname> interface as a placeholder to get us through the compiler. In dynamic
+ libraries, such as Smalltalk and Python, we don't even need to do that.
</para>
<programlisting>
@@ -141,22 +193,27 @@
void move(MoveRequest request);
}</programlisting>
+ <comment>From here!</comment>
-<para>Now I need to initialise a Robot with a Motor when I create it.
-Because I want to intercept the interaction between the Robot and its Motor
-I cannot let the Robot instantiate its own Motor; there would be no way to
-then intercept the Robot's movement requests. That leads me to pass a
-Motor instance to the Robot's constructor.</para>
-
-<para>I can now write my tests to create a Robot with an implementation
-of the <classname>Motor</classname> interface, that watches what's
-happening in the Robot, and complains as soon as something goes wrong.
-In fact, I will do this right now, before I start thinking about writing a
-real implementation of the Motor interface, so that I know my Robot
-implementation still works despite the extensive refactorings I have
-performed. The first test is now:</para>
+ <para>
+ Now I need to initialise a Robot with a Motor when I create it.
+ Because I want to intercept the interaction between the Robot and its Motor
+ I cannot let the Robot instantiate its own Motor; there would be no way to
+ then intercept the Robot's movement requests. That leads me to pass a
+ Motor instance to the Robot's constructor.
+ </para>
+
+ <para>
+ I can now write my tests to create a Robot with an implementation
+ of the <classname>Motor</classname> interface, that watches what's
+ happening in the Robot, and complains as soon as something goes wrong.
+ In fact, I will do this right now, before I start thinking about writing a
+ real implementation of the Motor interface, so that I know my Robot
+ implementation still works despite the extensive refactorings I have
+ performed. The first test is now:
+ </para>
-<programlisting>public void testGotoSamePlace() {
+ <programlisting>public void testGotoSamePlace() {
final Position POSITION = new Position(0, 0);
robot.setCurrentPosition(POSITION);
@@ -338,4 +395,4 @@
better. We hope that you can benefit from these techniques as well and that this book helps you to do so.
</para>
</section> <!-- Conclusions -->
-</chapter>
+</chapter>
\ No newline at end of file
Index: random.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/random.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- random.xml 9 Aug 2002 18:13:01 -0000 1.4
+++ random.xml 10 Aug 2002 23:43:41 -0000 1.5
@@ -1,28 +1,26 @@
<chapter status="draft">
-<title>Random Acts</title>
+ <title>Random Acts</title>
-<chapterinfo>
- <author>Nat Pryce</author>
- <copyright><year>2002</year> <holder>Nat Pryce</holder></copyright>
-</chapterinfo>
-
-<section>
-<title>Introduction</title>
-
-<remark>Expand this</remark>
-
-<para>
-Pseudo-random behaviour is used in many applications.
-In games it is used to portray natural behaviours that are too complex to
-simulate accurately, or to add variety to behaviours that are too predictable
-when simulated algorithmically.
-</para>
-
-<para>
-How do we test randomness?
-</para>
+ <chapterinfo>
+ <author>Nat Pryce</author>
+ <copyright><year>2002</year> <holder>Nat Pryce</holder></copyright>
+ </chapterinfo>
-</section>
+ <section>
+ <title>Introduction</title>
+
+ <comment>Expand this</comment>
+
+ <para>
+ Pseudo-random behaviour is used in many applications.
+ In games it is used to portray natural behaviours that are too complex to
+ simulate accurately, or to add variety to behaviours that are too predictable
+ when simulated algorithmically.
+ </para>
+
+ <comment>How do we test randomness?</comment>
+
+ </section>
<section>
<title>Come Rain...</title>
Index: htmlbook.css
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/htmlbook.css,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- htmlbook.css 10 Aug 2002 20:56:50 -0000 1.6
+++ htmlbook.css 10 Aug 2002 23:43:41 -0000 1.7
@@ -12,4 +12,5 @@
.sidebar { border: double black 1px; font-size: 80%; padding: 4px; text-align: center; margin-left: 80%; }
.screenshot { margin-left: 20%; }
.caption { font-size: 80%; font-style: italic; }
-.guibutton { font-weight: bold; }
\ No newline at end of file
+.guibutton { font-weight: bold; }
+.comment { font-style: italic; color: red; }
\ No newline at end of file
Index: extra_entities.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/extra_entities.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- extra_entities.xml 10 Aug 2002 18:10:08 -0000 1.4
+++ extra_entities.xml 10 Aug 2002 23:43:41 -0000 1.5
@@ -1,3 +1,5 @@
<!ENTITY redbar SYSTEM "file:@docpath@/red_bar.xml">
<!ENTITY greenbar SYSTEM "file:@docpath@/green_bar.xml">
-<!ENTITY elipsis "<emphasis>[...]</emphasis>" >
\ No newline at end of file
+
+<!ENTITY elipsis "<emphasis>[...]</emphasis>" >
+<!ENTITY todo "<comment>To Do</comment>" >
|
