Best practices in writing OpenACS automated tests
-Special characters in Tcl. Try strings
-starting with a -Bad and
-strings containing [BAD],
+Special characters in Tcl. Try
+strings starting with a -Bad
+and strings containing [BAD],
{, \077, and $Bad. For user input, [BAD] should never be evaluated,
\077 should not be turned into
a ? and $Bad should not be interpolated. The string
-Bad [BAD] \077 { $Bad should
be valid user input, should pass through the system unaltered, and
-if it isn't that's a bug.
-Quoting issues. Put some html in plain text
-fields and make sure the result is properly quoted anywhere it
-shows up (I use "<b>bold</b>" 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
-& to check that the
-field is quoted properly. If it is not displayed as & then the quoting for the field is
-incorrect. (It'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 and we should not
-rely on input validation to prevent XSS security holes.)
-Whitespace input. 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 used to construct a
-link and if it is " " it will have a link of <a href="..."> </a> which would
-not be clickable if whitespace was allowed as a valid input.
-Doubleclick. Make sure that if you submit a -form, use the back button, and submit again that the behavior is -reasonable (correct behavior depends on what the form is for, but a -server error is not reasonable).
-Duplicate names. Make sure that if a -duplicate name is entered that there is a reasonable error rather +if it isn't that's a bug.
+Quoting issues. Put some html in
+plain text fields and make sure the result is properly quoted
+anywhere it shows up (I use "<b>bold</b>"
+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 & to
+check that the field is quoted properly. If it is not displayed as
+& then the quoting for
+the field is incorrect. (It'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
+and we should not rely on input validation to prevent XSS security
+holes.)
+Whitespace input. 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 used to
+construct a link and if it is " " it will have a link of
+<a href="...">
+</a> which would not be clickable if whitespace was
+allowed as a valid input.
+Doubleclick. Make sure that if you +submit a form, use the back button, and submit again that the +behavior is reasonable (correct behavior depends on what the form +is for, but a server error is not reasonable).
+Duplicate names. Make sure that if +a duplicate name is entered that there is a reasonable error rather than a server error. Check for insert, move, copy, and rename.