Index: openacs-4/packages/acs-core-docs/www/automated-testing-best-practices.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/automated-testing-best-practices.html,v
diff -u -r1.28.2.10 -r1.28.2.11
--- openacs-4/packages/acs-core-docs/www/automated-testing-best-practices.html	21 Jun 2016 07:44:35 -0000	1.28.2.10
+++ openacs-4/packages/acs-core-docs/www/automated-testing-best-practices.html	23 Jun 2016 08:32:45 -0000	1.28.2.11
@@ -3,15 +3,15 @@
           OpenACS docs are written by the named authors, and may be edited
           by OpenACS documentation staff.
         </div><p>Best practices in writing OpenACS automated tests</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><b>Special characters in Tcl. </b>
-Try strings starting with a <code class="computeroutput">-Bad</code> and strings containing <code class="computeroutput">[BAD]</code>, <code class="computeroutput">{</code>, <code class="computeroutput">\077</code>, and <code class="computeroutput">$Bad</code>.  For user input, <code class="computeroutput">[BAD]</code> should never be evaluated, <code class="computeroutput">\077</code> should not be turned into a <code class="computeroutput">?</code> and <code class="computeroutput">$Bad</code> should not be interpolated.  The string <code class="computeroutput">-Bad [BAD] \077 { $Bad</code> should be valid user input, should pass through the system unaltered, and if it isn't that's a bug.
+Try strings starting with a <code class="computeroutput">-Bad</code> and strings containing <code class="computeroutput">[BAD]</code>, <code class="computeroutput">{</code>, <code class="computeroutput">\077</code>, and <code class="computeroutput">$Bad</code>.  For user input, <code class="computeroutput">[BAD]</code> should never be evaluated, <code class="computeroutput">\077</code> should not be turned into a <code class="computeroutput">?</code> and <code class="computeroutput">$Bad</code> should not be interpolated.  The string <code class="computeroutput">-Bad [BAD] \077 { $Bad</code> should be valid user input, should pass through the system unaltered, and if it isn&#39;t that&#39;s a bug.
 </p></li><li class="listitem"><p><b>Quoting issues. </b>Put some html in plain text fields and make sure the result is
 properly quoted anywhere it shows up (I use "&lt;b&gt;bold&lt;/b&gt;"
 usually).  Look out especially for quoting errors in the context bar
 and in round trips via an edit form. For fields that disallow html
 tags you can use <code class="computeroutput">&amp;amp;</code> to check that the field is quoted
-properly.  If it is not displayed as <code class="computeroutput">&amp;amp;</code> then the quoting for the field is incorrect. (It's not clear whether this
+properly.  If it is not displayed as <code class="computeroutput">&amp;amp;</code> then the quoting for the field is incorrect. (It&#39;s not clear whether this
 should be considered an error but given that data for text fields can
-come from various sources if it's text it should be properly quoted
+come from various sources if it&#39;s text it should be properly quoted
 and we should not rely on input validation to prevent XSS security
 holes.)</p></li><li class="listitem"><p><b>Whitespace input. </b>Check that whitespace is not considered valid input for a field
 if it does not make sense.  For example, the subject of a forum post is