|
From: Steve F. <sm...@us...> - 2002-08-04 11:13:31
|
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 -->
|