[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

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

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>
 
-    &notes;
+    &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>
       &mdash; 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