[Mockobjects-java-dev] CVS: doc another_route.html,1.1,1.2

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

Update of /cvsroot/mockobjects/doc
In directory usw-pr-cvs1:/tmp/cvs-serv2889

Modified Files:
	another_route.html 
Log Message:
end of the first test

Index: another_route.html
===================================================================
RCS file: /cvsroot/mockobjects/doc/another_route.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- another_route.html	2001/08/27 11:21:20	1.1
+++ another_route.html	2001/08/27 17:50:07	1.2
@@ -19,6 +19,10 @@
 <h1>Another approach to working backwards</h1>
 <p align="center">Steve Freeman <tt> &nbsp;&lt;st...@m3...&gt;</tt></p>
 <h2>Introduction</h2>
+<p>The &quot;Chicago School&quot; of writing mock objects is interestingly different 
+  from the approach we take in London. To examine these differences, I have rewritten 
+  the password reminder example taken from XP in Practice.</p>
+<h2>The first test</h2>
 <h3>Send a reminder</h3>
 <p>The first test assumes success and should check that an email is sent and that 
   the user is redirected to a success page. How can we test these? Redirects are 
@@ -72,8 +76,45 @@
     passwordReminder.sendReminder(emailAddress);
     response.sendRedirect(SENT_URI + "?" + EMAIL_PARAM + "=" + emailAddress);
   }
+</pre>
+<h3>A mock password reminder</h3>
+<p>The servlet code tells us that the interface for a password reminder class 
+  needs just a single method.</p>
+<pre>  public interface PasswordReminder {
+    public void sendReminder(String emailAddress);
+  }</pre>
+<p>The implementation of a mock password reminder is very simple; it is based 
+  on an expectation class from the mockobjects library.</p>
+<pre>  public class MockPasswordReminder extends MockObject implements PasswordReminder {
+    private ExpectationValue emailAddress = 
+      new ExpectationValue("MockPasswordReminder email");
+
+    public void sendReminder(String anEmailAddress) {
+        emailAddress.setActual(anEmailAddress);
+    }
 
- </pre>
+    public void setExpectedEmailAddress(String anEmailAddress) {
+        emailAddress.setExpected(anEmailAddress);
+    }
+  }
+</pre>
+<p>An <span class="inline_code">ExpectationValue</span> will throw an assertion 
+  failed exception if the value passed to the <span class="inline_code">setActual()</span> 
+  method is not equal to the value passed to the <span class="inline_code">setExpected()</span> 
+  method. It will also fail when calling <span class="inline_code">verify()</span>, 
+  inherited from <span class="inline_code">MockObject</span>, if no actual value 
+  has been set during the test. An expectation defines an interaction that should 
+  take place between the target code and the mock object if the test runs successfully&#151;something 
+  between an invariant and post-condition. </p>
+<h3>Differences</h3>
+<p>There are two obvious differences to the original so far. First, we start at 
+  the top level of the problem, from outside the servlet, rather than from an 
+  internal object. Second, we perfer to pass our test infrastructure into the 
+  target code, as Mock Objects, rather than use techniques such as inner classes 
+  to give us access to private data. This means that we tend to define our assertions 
+  at the beginning of test, rather than at the end.</p>
+<p><br>
+</p>
 <hr>
 <p>&copy; Steve Freeman, 2001</p>
 <p>&nbsp; </p>