Menu
▾
▴
[MO-java-dev] CVS: no-stone-unturned/doc/xdocs part_servlets.xml,NONE,1.1 resources.xml,NONE,1.1 htmlbook.xsl,1.9,1.10 doc-book.xml,1.11,1.12 testing_guis_1.xml,1.8,1.9 how_mocks_happened.xml,1.11,1.12 htmlbook.css,1.11,1.12
Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv32157/doc/xdocs
Modified Files:
htmlbook.xsl doc-book.xml testing_guis_1.xml
how_mocks_happened.xml htmlbook.css
Added Files:
part_servlets.xml resources.xml
Log Message:
bits of tidy up and formatting
--- NEW FILE: part_servlets.xml ---
<part status="draft">
<title>A longer example</title>
<partintro>
<para>
So far, I've covered some basic ideas and attempted to explain why &TDD; is so useful. Now it's
time to follow through with a longer example. I've picked a Java servlet, because that's where
we initially worked out these ideas
<footnote>
<para>
One of the key moments in the develoment of our unit testing skills was when Oli Bye,
while programming on a train, got fed up with trying to test against a live
Web server and generated stub implementations of the Java servlet interfaces using
<productname>VisualAge for Java</productname>. That's when we realized what we
could do if we tested code outside its target environment
</para>
</footnote>, and because they provide a nice example framework with reasonably
clean interfaces.
</para>
</partintro>
&chp_servlets_1;
&chp_servlets_2;
&chp_servlets_3;
</part>
--- NEW FILE: resources.xml ---
<appendix status="todo" id="appendix_resources">
<title>Resources</title>
&TODO;
<para>Testing frameworks - Graphical</para>
</appendix>
Index: htmlbook.xsl
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/htmlbook.xsl,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- htmlbook.xsl 17 Aug 2002 13:20:07 -0000 1.9
+++ htmlbook.xsl 21 Aug 2002 19:16:43 -0000 1.10
@@ -15,8 +15,10 @@
<xsl:param name="callout.defaultcolumn" select="'80'"/>
<xsl:param name="callout.graphics.path" select="'images/style/callouts/'"/>
<xsl:param name="toc.section.depth">1</xsl:param>
+ <xsl:param name="emphasis.propagates.style" select="1"/>
- <xsl:template name="inline.gui">
+ <xsl:template name="inline.span">
+ <xsl:param name="spanclass" select="none"/>
<xsl:param name="content">
<xsl:call-template name="anchor"/>
<xsl:call-template name="simple.xlink">
@@ -25,27 +27,34 @@
</xsl:with-param>
</xsl:call-template>
</xsl:param>
- <span class="guibutton"><xsl:copy-of select="$content"/></span>
+ <span class="{$spanclass}"><xsl:copy-of select="$content"/></span>
</xsl:template>
- <xsl:template match="guibutton">
- <xsl:call-template name="inline.gui"/>
+
+ <xsl:template match="lineannotation">
+ <xsl:call-template name="inline.span">
+ <xsl:with-param name="spanclass" select="'lineannotation'" />
+ </xsl:call-template>
</xsl:template>
- <xsl:template name="inline.comment">
- <xsl:param name="content">
- <xsl:call-template name="anchor"/>
- <xsl:call-template name="simple.xlink">
- <xsl:with-param name="content">
- <xsl:apply-templates/>
- </xsl:with-param>
- </xsl:call-template>
- </xsl:param>
- <span class="comment"><xsl:copy-of select="$content"/></span>
+ <xsl:template match="guibutton">
+ <xsl:call-template name="inline.span">
+ <xsl:with-param name="spanclass" select="'guibutton'" />
+ </xsl:call-template>
</xsl:template>
<xsl:template match="comment">
- <xsl:call-template name="inline.comment"/>
+ <xsl:call-template name="inline.span">
+ <xsl:with-param name="spanclass" select="'comment'" />
+ </xsl:call-template>
+ </xsl:template>
+
+ <xsl:template match="comment|remark">
+ <xsl:if test="$show.comments != 0">
+ <xsl:call-template name="inline.span">
+ <xsl:with-param name="spanclass" select="'remark'" />
+ </xsl:call-template>
+ </xsl:if>
</xsl:template>
<xsl:param name="generate.toc">
Index: doc-book.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/doc-book.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- doc-book.xml 18 Aug 2002 01:42:12 -0000 1.11
+++ doc-book.xml 21 Aug 2002 19:16:43 -0000 1.12
@@ -11,12 +11,16 @@
<!ENTITY chp_servlets_1 SYSTEM "file://@docpath@/servlets_1.xml">
<!ENTITY chp_servlets_2 SYSTEM "file://@docpath@/servlets_2.xml">
<!ENTITY chp_servlets_3 SYSTEM "file://@docpath@/servlets_3.xml">
+ <!ENTITY part_servlets SYSTEM "file://@docpath@/part_servlets.xml">
+
<!ENTITY chp_jdbc_testfirst SYSTEM "file://@docpath@/jdbc_testfirst.xml">
<!ENTITY part_testing_guis SYSTEM "file://@docpath@/testing_guis_1.xml">
<!ENTITY chp_random SYSTEM "file://@docpath@/random.xml">
- <!ENTITY notes SYSTEM "file://@docpath@/notes.xml">
+ <!ENTITY part_notes SYSTEM "file://@docpath@/notes.xml">
+
+ <!ENTITY appendix_resources SYSTEM "file://@docpath@/resources.xml">
<!ENTITY patterns SYSTEM "file://@docpath@/patterns.xml">
<!ENTITY glossary SYSTEM "file://@docpath@/glossary.xml">
@@ -46,13 +50,7 @@
&preface;
&part_introduction;
-
- <part status="draft">
- <title>A longer example</title>
- &chp_servlets_1;
- &chp_servlets_2;
- &chp_servlets_3;
- </part>
+ &part_servlets;
<part status="draft">
<title>Working with third party libraries</title>
@@ -136,8 +134,10 @@
&TODO;
</appendix>
- ¬es;
+ &appendix_resources;
</part>
+
+ &part_notes;
&glossary;
</book>
Index: testing_guis_1.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/testing_guis_1.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- testing_guis_1.xml 18 Aug 2002 22:44:39 -0000 1.8
+++ testing_guis_1.xml 21 Aug 2002 19:16:43 -0000 1.9
@@ -13,7 +13,13 @@
to a business layer. That's probably why there are no tests for the graphical test runners for
<application>JUnit</application>. This is still good advice but it doesn't feel good enough, given
how much we say we believe in the benefits of writing the tests first. Now we have a better handle on how to
- work with graphical environments (or at least some of them). Let's see something working.
+ work with graphical environments (or at least some of them).
+ </para>
+ <para>
+ There are now several toolkits available for testing graphical user interfaces, some are listed in
+ <xref linkend="appendix_resources" />. I won't be using any of them here because I want to get there
+ from scratch, so you understand how things work. In practice, I'd pick one of the toolkits to get the
+ job done. Now, let's see something working.
</para>
</partintro>
Index: how_mocks_happened.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/how_mocks_happened.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- how_mocks_happened.xml 20 Aug 2002 16:56:58 -0000 1.11
+++ how_mocks_happened.xml 21 Aug 2002 19:16:43 -0000 1.12
@@ -706,39 +706,44 @@
<para>
&TDD; is about design, it's a way of specifying behaviour and the relationships between objects
- in a system. What influence does using Mock Objects have on the eventual structure of a system?
+ in a system. What influence does using Mock Objects have on the eventual structure of the code?
Let's start by asking where the significant <quote>design moments</quote> are when
developing this way.
</para>
<para>
As we begin a new test, the first question we ask is, <quote>Who would know?</quote>
— if we were to implement this functionality, which objects would it affect? The answer
- will tell us which objects need to interact with the code under test, and the
- the relationships between them. For example, we decided that we needed a <quote>route following
- object</quote>, called a <quote>Motor</quote>, so that we could tell whether the route
- had been properly constructed; we invented a construct in the software to represent something
- in the physical world. This is what Object-Oriented Design is about, and we have a way to
- drive that decision from an immediate requirement in a test. A motor is a straightforward
- concept, in later examples I'll show how we can be more sophisticated and invent objects to
- represent computatational concepts such as callbacks and listeners.
+ will tell us which objects need to interact with the code under test. For example, we
+ decided that we needed a <quote>route following object</quote>, a
+ <classname>Motor</classname>, so that we could tell whether the route
+ has been properly constructed; we invented a construct in the software to represent something
+ in the physical world. This sounds to me like Object-Oriented Design (or at least some of it),
+ and we have found a way to drive that decision from an immediate requirement in a test.
+ A motor is straightforward, in later examples I'll show how we can be more sophisticated and
+ invent objects to represent computatational concepts such as callbacks and listeners.
</para>
<para>
- The next decision was how to make the motor object available to the robot object so that it
- can move. We could have passed the <classname>Motor</classname> through to the
+ The next decision was how to connect the motor object to the robot object, so that it
+ can move. We could have passed the <classname>Motor</classname> through with the
<function>goTo()</function> method, but instead we decided to make the <classname>Motor</classname>
part of the <classname>Robot</classname> and pass it through in the constructor. That's another
design decision and, again, we drove it from the process of writing a test.
</para>
<para>
+ We've added a very simple
+ </para>
+
+ <para>
We want to unit test but don't want to expose more of the internals of the object than is necessary,
- because that makes the class, and the code that uses it, that little bit harder to change. Across a
+ because that makes the class, and the code that uses it, that little bit harder to change; across a
whole code base, the increased <quote>refactoring drag</quote> can be significant. Our solution
- (<quote>Tell, don't ask</quote>) forces us into passing around computation rather than data: we
- pass a <quote>route listening object</quote> (a <classname>Motor</classname>) to
- the <classname>Robot</classname>, rather than returning a collection of <classname>MoveRequest</classname>.
+ (<quote>Tell, don't ask</quote>) forces us into passing around computation rather than data, which is
+ why we used the <quote>route following object</quote>, rather than returning a collection
+ of <classname>MoveRequest</classname>.
</para>
<sidebar>
+ <title>Top-Down Decomposition</title>
<para>
Some of you may recognise the similarities between &TDD; and the ancient discipline of
<glossterm linkend="topdowndecomposition"><quote>Top-Down Decomposition</quote></glossterm>, also known as
@@ -751,10 +756,10 @@
<para>
Top-Down Decomposition had two powerful insights: to keep each level focussed and consistent,
and to drive the design of interfaces from their use rather than their implementation. It also had
- a couple of critical failings, because it turned out to be hard to change early design
- decisions which, of course, are embedded in the top-level structure, and it's not good at
+ a couple of critical failings: it turned out to be hard to change early design
+ decisions because, of course, they're embedded in the top-level structure, and it's not good at
encouraging reuse between lower-level components. It looks like &TDD; avoids those failures because
- of its emphasis on refactoring and because objects give us better modularity than procedures.
+ of its emphasis on refactoring.
</para>
</sidebar>
</section> <!-- What about design? -->
@@ -825,12 +830,6 @@
out to be the flex points I need as the use of the code evolves.
</para>
</section> <!-- What does this mean? -->
-
- <section status="todo">
- <title>Notes</title>
- <!-- TODO -->
- <para>Top-down decomposition</para>
- </section>
<section>
<title>Conclusions</title>
Index: htmlbook.css
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/htmlbook.css,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- htmlbook.css 20 Aug 2002 16:56:58 -0000 1.11
+++ htmlbook.css 21 Aug 2002 19:16:43 -0000 1.12
@@ -1,23 +1,41 @@
/* htmlbook.css, a stylesheet for htmlbook */
-BODY { font-family: Arial, Helvetica, sans-serif}
-H1 { margin-top: 5%; }
-H2 { margin-top: 3%;}
-
-DIV.section H2 { font-style: italic; font-weight: normal; }
-DIV.section H3 { font-style: normal; font-size: small; }
-DIV.tip H3 { font-style: italic; font-weight: normal; font-size: small; }
+/* BODY { font-family: Arial, Helvetica, sans-serif} */
+BODY { font-family: "Century Schoolbook", Times, serif; }
+H1 { font-family: Arial, Helvetica, sans-serif; margin-top: 5%; }
+H2 { margin-top: 3%; font-style: italic;}
+
+DIV.chapter H2 { font-family: Arial, Helvetica, sans-serif;
+ font-weight: normal; font-size: 200%; }
+DIV.preface H2 { font-family: "Century Schoolbook", Times, serif;
+ font-weight: normal; font-size: 140%; }
+DIV.section H2 { font-family: "Century Schoolbook", Times, serif;
+ font-weight: normal; font-size: 140%; }
+DIV.section H3 { font-style: italic; font-weight: normal; }
+
+.tip { border: solid black 1px; }
+DIV.tip H3 { font-size: 80%; font-style: italic; font-weight: normal; font-size: small; }
DIV.tip P { font-size: 80%; }
+
+.note { border: solid black 1px;}
+DIV.note { margin-left: 10%; };
DIV.note TH { font-size: 80%; }
DIV.note P { font-size: 80%; }
+
+.sidebar { border-top: solid black 1px; border-bottom: solid black 1px;
+ font-family: Arial, Helvetica, sans-serif; font-size: 80%;
+ padding: 2%; margin-left: 10%; margin-right: 5%;
+ }
+DIV.sidebar P { margin-top: 10px; margin-bottom: 10px; }
+DIV.sidebar P.title { margin-top: 0%; font-style: italic; font-size: 130%; }
+
PRE SPAN.emphasis { font-weight: bold; }
-.programlisting { margin-left: 5%; }
-.screen { margin-left: 5%; }
-.sidebar { border: double grey 5px; font-size: 80%; padding: 2%; margin-left: 10%; margin-right: 10%; }
-.tip { border: double black 1px; }
-.note { border: double black 1px;}
-.screenshot { margin-left: 20%; }
-.caption { font-size: 80%; font-style: italic; }
-.guibutton { font-weight: bold; }
-.comment { font-style: italic; color: red; }
\ No newline at end of file
+.lineannotation { font-style: italic; font-family: "Century Schoolbook", Times, serif; }
+.footnote { margin-left: 5%; text-indent: -3% }
+.programlisting { margin-left: 5%; }
+.screen { margin-left: 5%; }
+.screenshot { margin-left: 20%; }
+.caption { font-size: 80%; font-style: italic; }
+.guibutton { font-weight: bold; }
+.remark { font-style: italic; color: red; }
\ No newline at end of file
|
