Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv14284/doc/xdocs
Modified Files:
how_mocks_happened.xml
Log Message:
more rework
Index: how_mocks_happened.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/how_mocks_happened.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- how_mocks_happened.xml 21 Aug 2002 19:57:21 -0000 1.13
+++ how_mocks_happened.xml 22 Aug 2002 11:28:31 -0000 1.14
@@ -730,10 +730,20 @@
design decision and, again, we drove it from the process of writing a test.
</para>
<para>
- Design by composition, top-down with polymorphism, do the protocols first, shows the fault lines but
- it's more than divide and conquer.
+ We're designing each unit of code from the outside-in, from how the caller sees it. When we
+ program, writing tests with Mock Objects makes us think about the objects it
+ depends on, its environment. Sometimes those objects don't yet exist, which means that we've
+ found a conceptual <quote>fault line</quote> in the system that we can turn into
+ a new object interface. In our tests, we describe what the objects should say to each other,
+ their <emphasis>protocol</emphasis>, without having to figure out how the new objects actually
+ work. Applied consistently, this pushes us towards a codebase made up of components with
+ clear interfaces which (so I've been led to believe) makes good things like reusability
+ happen almost as a byproduct. What makes &TDD; so powerful is that we can do
+ all this incrementally, evolving the code from the requirements in hand rather than
+ having to place bets on the what we think we're going to need.
</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
@@ -760,12 +770,18 @@
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.
+ object-orientation makes it easier to share and replace components throughout the application and
+ because its emphasis on refactoring means we can adjust as the codebase grows.
</para>
</sidebar>
</section> <!-- What about design? -->
<!-- TODO --> <comment>Under development</comment>
+ <para>
+ Design by composition, top-down with polymorphism, do the protocols first, shows the fault lines but
+ it's more than divide and conquer.
+ </para>
+
<section>
<title>What does this mean?</title>
|
