[Dealing with the module abstraction boundary and QuickCheck
Don Stewart <dons@galois.com>**20080512052148] {
hunk ./en/ch12-testing.xml 41
-with GHC's code coverage tool: HPC.
+with &GHC;'s code coverage tool: HPC.
hunk ./en/ch12-testing.xml 210
-    <title>Testing case study: specifying JSON printing</title>
+    <title>Testing case study: specifying a pretty printer</title>
+
+    <para>Testing individiual functions for their algebraic properties is one
+      of the basic building blocks when developing large systems in Haskell. 
+      We'll look at a more complicated scenario now: taking the pretty
+      printing library developed in earlier chapters, and thoroughly testing
+      it. 
+    </para>
hunk ./en/ch12-testing.xml 221
+  <!-- TODO: expand further on the abstraction boundary scenarios -->
+
+    <para>An issue that comes up when testing with QuickCheck is where 
+    to place the properties. Do they live in an external testsuite, or should 
+    they be considered part of the module they test? This becomes more of an
+    issue when the testsuite needs to break the module abstraction boundaries
+    we have in place (for example, we might need access to constructors that
+    are normally hidden). For our pretty printer, this means we'll need, for
+    testing purposes, to expose the constructors of the Doc type, in order
+    for us to generate random document values.
+    </para>
+
}