[MO-java-dev] CVS: no-stone-unturned/doc/xdocs testing_guis_1.xml,1.3,1.4

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

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

Modified Files:
	testing_guis_1.xml 
Log Message:
Started second GUI test

Index: testing_guis_1.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/testing_guis_1.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- testing_guis_1.xml	4 Aug 2002 01:41:47 -0000	1.3
+++ testing_guis_1.xml	4 Aug 2002 11:13:28 -0000	1.4
@@ -375,7 +375,7 @@
 
       <programlisting>
 public interface Directory {
-  String lookFor(String searchString);
+  String search();
 }</programlisting>
 
       <para>
@@ -385,7 +385,7 @@
       <programlisting>
 public void testNoMatchesFound() {
   Searcher searcher = new Searcher(<emphasis>new Directory() {
-    public String lookFor(String searchString) {
+    public String search() {
       return null;
     }
   }</emphasis>);
@@ -393,7 +393,7 @@
 
 public void testOneMatchFound() {
   Searcher searcher = new Searcher(<emphasis>new Directory() {
-    public String lookFor(String searchString) {
+    public String search() {
       return "One Result";
     }
   }</emphasis>);
@@ -443,7 +443,7 @@
 
   searchButton.addActionListener(new ActionListener() {
       public void actionPerformed(ActionEvent e) {
-        <emphasis>String result = directory.lookFor("");
+        <emphasis>String result = directory.search();
         if (null == result) {
           statusBar.setText("No entries found");
         } else {
@@ -470,19 +470,75 @@
     <sect1>
       <title>Expecting the search string</title>
       <para>
-        We're missing an important part of the behaviour, there's no way for users to specify what they're looking
-        for. The <classname>ActionListener</classname> simply passes an empty string to the
-        <classname>Directory</classname>. Looking again, the requirements say nothing about a user typing in a
-        search string, everybody just assumed it. Clearly this is a contrived example, but these things do happen in
-        the Real World. The nice thing about the early feedback from incremental development is that you discover
-        problems when you still have time to do something about them, rather than after all the time (and money) has
-        been spent. We confirm our suspicions with our customer that they actually wanted to be able to enter search
-        strings and go back to work on the tests.
+        We're missing some important behaviour, there's no way for users to specify what they're looking
+        for. The <function>search</function> method does not expect any input values. Looking again, the
+        requirements say nothing about a user typing in a search string, everybody just assumed it.  We confirm our
+        suspicions with our customers that they actually wanted to be able to enter a search string and go back to
+        work on the tests.
       </para>
+
+      <para>
+        Now we need a text field for the search string, and we need to make sure that the contents of this field is
+        passed to the <classname>Directory</classname> at the beginning of a search. We'll change
+        <function>search()</function> to <function>searchFor(String searchString)</function> to reflect its new
+        function. We rework the test as follows:
+      </para>
+
+      <programlistingco>
+        <areaspec>
+          <area id="testOneMatchFound.1" coords="12" />
+        </areaspec>
+        <programlisting>
+public void testOneMatchFound() {
+  final ExpectationValue searchString = new ExpectationValue("search string");
+
+  Searcher searcher = new Searcher(new Directory() {
+    public String lookFor(String aSearchString) {
+      searchString.setActual(aSearchString);
+      return "One Result";
+    }
+  });
+
+  ((JTextField)findNamedComponent(searcher, "search criterion")).setText("Search String");
+
+  searchString.setExpected("Search String");
+  ((JButton)findNamedComponent(searcher, "search button")).doClick();
+
+  assertEquals("Should be result",
+               "One Result",
+               ((JTextArea)findNamedComponent(searcher, "results")).getText());
+  assertEquals("Should be status",
+               "",
+               ((JLabel)findNamedComponent(searcher, "status")).getText().trim());
+}</programlisting>
+      <para>I'll step through the changes we've made.</para>
+      <calloutlist>
+        <callout arearefs="testOneMatchFound.1">
+          <para>
+            We need a <classname>JTextField</classname> for people to type in their search criterion; that's not an
+            interesting failure, so I'll just fix that one.
+          </para>
+        </callout>
+      </calloutlist>
+
+      <!--
+        First, we need a <classname>JTextField</classname> for people to type in their search criterion; that's not an
+        interesting failure, so I'll just fix that one. Next, we want to ensure that the contents of that text field is
+        passed through to the directory object, so we preload the text field and define an expectation
+      -->
+    </programlistingco>
+
     </sect1> <!-- Expecting the search string -->
 
     <sect1>
       <title>What have we learned?</title>
+      <para>
+        Clearly this is a contrived example, but these things do happen in
+        the Real World. The nice thing about the early feedback from incremental development is that you discover
+        problems when you still have time to do something about them, rather than after all the time (and money) has
+        been spent.
+      </para>
+
     </sect1> <!-- What have we learned? -->
 
   </chapter> <!-- Second test -->