[MO-java-dev] CVS: no-stone-unturned/doc/xdocs how_mocks_happened.xml,1.1,1.2

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv10339/doc/xdocs

Modified Files:
	how_mocks_happened.xml 
Log Message:
corrected some tags

Index: how_mocks_happened.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/how_mocks_happened.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- how_mocks_happened.xml	9 Aug 2002 23:49:40 -0000	1.1
+++ how_mocks_happened.xml	10 Aug 2002 12:22:26 -0000	1.2
@@ -50,7 +50,7 @@
       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 <methodname>goto()</methodname>. For example:
+      be to store and retrieve the route it took after each <function>goto()</function>. For example:
     </para>
 
     <programlisting>
@@ -95,7 +95,7 @@
 }</programlisting>
 
     <para>
-      where <methodname>makeExpectedLongWayMoves()</methodname> returns a list of the
+      where <function>makeExpectedLongWayMoves()</function> returns a list of the
       moves we expect the robot to make for this test.
     </para>
 
@@ -105,8 +105,8 @@
       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.
       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 <methodname>goto()</methodname>.
-      We don't have any other immediate need for <methodname>getRecentMovesRequests()</methodname>.
+      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>.
       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
@@ -130,10 +130,10 @@
       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 <interfacename>Motor</interfacename>. We know that
-      there must be some kind of request, which we'll call <methodname>move()</methodname>, that takes a
+      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
-      <interfacename>MoveRequest</interfacename> interface as a placeholder to get us through the compiler.
+      <classname>MoveRequest</classname> interface as a placeholder to get us through the compiler.
     </para>
 
     <programlisting>
@@ -149,7 +149,7 @@
 Motor instance to the Robot's constructor.</para>
 
 <para>I can now write my tests to create a Robot with an implementation
-of the <interfacename>Motor</interfacename> interface, that watches what's
+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
@@ -176,7 +176,7 @@
 
 <para>In this test, if there is a bug in the Robot code and the Motor
 gets requested to move, the mock implementation of 
-<methodname>move()</methodname>
+<function>move()</function>
 will fail immediately and stop the test; I no longer need to ask the Robot
 where it's been.</para>
 
@@ -264,7 +264,7 @@
 <para>My code moved in this direction because I was committed to unit
 testing but didn't want to record and expose unnecessary details about the
 state of my Robot 
-(the <methodname>getRecentMoveRequests()</methodname> method).
+(the <function>getRecentMoveRequests()</function> method).
 As a result, I have better unit tests and a cleaner interface to the Robot
 class.  But even better than that, by following the needs of my tests I have
 actually ended up improving the object model of the Robot by separating the