[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs/papers brief_introduction.html,1.2,1.3

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

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs/papers
In directory usw-pr-cvs1:/tmp/cvs-serv22896

Modified Files:
	brief_introduction.html 
Log Message:
more

Index: brief_introduction.html
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/papers/brief_introduction.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- brief_introduction.html	2001/10/27 23:37:05	1.2
+++ brief_introduction.html	2001/11/03 00:33:31	1.3
@@ -2,9 +2,9 @@
 <html>
 <head>
   <title>Developing JDBC applications test-first</title>
-                                                          
+
   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-                                 
+
   <style type="text/css">
 <!--
 .deemphasised {  color: #666666}
@@ -87,7 +87,7 @@
   assertEquals("Should be destination", DESTINATION, robot.getPosition());
   List moves = robot.getRecentMoveRequests();
   assertEquals("Should be one move", 1, moves.size());
-  assertEquals("Should be same move", 
+  assertEquals("Should be same move",
                new MoveRequest(1, MoveRequest.SOUTH), moves.get(1));
 }</pre>
 
@@ -100,7 +100,7 @@
   robot.goto(DESTINATION);
 
   assertEquals("Should be destination", DESTINATION, robot.getPosition());
-  assertEquals("Should be same moves", 
+  assertEquals("Should be same moves",
                makeExpectedLongWayMoves(), robot.getRecentMoves());
 }</pre>
 
@@ -149,8 +149,8 @@
 }</pre>
 
 <p>I can now refactor my tests and replace the real Motor with a
-MockMotor that can watch what's happening in the Robot and complain as
-soon as something goes wrong. My first test is now:</p>
+MockMotor that can watch what's happening in the Robot, and complain as
+soon as something goes wrong. The first test is now:</p>
 
 <pre>public void testGotoSamePlace() {
   final Position POSITION = new Position(0, 0);
@@ -162,7 +162,7 @@
     }
   };
   robot.setMotor(mockMotor);
-                   
+
   robot.goTo(POSITION);
 
   assertEquals("Should be same", POSITION, robot.getPosition());
@@ -170,16 +170,16 @@
 
 <p>In this test, if there is a bug in the Robot code and the Motor
 gets requested to move, the mock implementation of <em>move()</em>
-will simply fail and stop the test. I no longer need to ask the Robot
-where it's been. I can write a more sophisticated MockMotor that works
-for multiple requests and use it throughout all the Robot tests; for
-example:</p>
+will fail immediately and stop the test; I no longer need to ask the Robot
+where it's been. As my tests grow, I can refactor the various mock implementations
+into a single, more sophisticated MockMotor and use it throughout all the Robot
+tests; for example:</p>
 
 <pre>public void MockMotor implements Motor {
   private ArrayList expectedRequests = new ArrayList();
   public void move(MoveRequest request) {
     assert("Too many requests", this.expectedRequests.size() &gt; 0);
-    assertEquals("Should be next request", 
+    assertEquals("Should be next request",
                  this.expectedRequests.remove(0), request);
   }
   public void addExpectedRequest(MoveRequest request) {
@@ -198,7 +198,7 @@
   public void setUp() {
     mockMotor = new MockMotor();
     robot = new Robot(mockMotor);
-    robot.setCurrentPosition(POSITION);
+    robot.setCurrentPosition(ORIGIN);
   }
   public void testGotoSamePlace() {
     robot.goTo(ORIGIN);
@@ -216,12 +216,34 @@
     assertEquals("Should be destination", DESTINATION, robot.getPosition());
     mockMotor.verify();
   }
+  public void testMoveALongWay() {
+    final Position DESTINATION = new Position(34, 71);
+
+    mockMotor.addExpectedRequests(makeExpectedLongWayMoveRequests());
+
+    robot.goto(DESTINATION);
+
+    assertEquals("Should be destination", DESTINATION, robot.getPosition());
+    mockMotor.verify();
 }</pre>
 
-<p>What has this change achieved? 
-</p>
+<h2>What has this change achieved?</h2>
+<ul>
+   <li><em>Refactored test infrastructure</em> As my tests grow, I find myself repeating my test
+     infrastructure. I can push those repetitions into mock implementations, based on the
+     expectation types that ship with the Mock Objects library. </li>
+   <li><em>Failing early</em> A key experience of developing test-first is learning to make test
+     failures self explanatory. Failing at the time an error occurs with a useful message,
+     rather than at the end of the test, is a powerful tool.</li>
+   <li><em>Driving design</em> Choosing which objects to verify in a test turns out to be an
+     effective tool for deriving the structure of a class and its neighbours.</li>
+   <li><em>Consistent test structure</em> Most unit tests in this style have a similar structure:
+     set up the objects (pre-conditions), set the expected behaviour (invariants and
+     post-conditions), exercise the object, and then verify whether the expectations were
+     fufilled. This style makes tests easy to work with because they look similar and because
+     all the interactions with an object are local to a test fixture.</li>
+</ul>
 <hr>
-<p>&copy; Steve Freeman, 2001</p>
-<p>&nbsp; </p>
+<p>&copy; Steve Freeman 2001</p>
 </body>
 </html>