[Tutor] the art of testing

[Serdar Tumgoren]

> That's a good start.  You're missing one requirement that I think needs to
> be explicit.  Presumably you're requiring that the XML be well-formed.  This
> refers to things like matching <xxx>  and </xxx> nodes, and proper use of
> quotes and escaping within strings.  Most DOM parsers won't even give you a
> tree if the file isn't well-formed.

I actually hadn't been checking for well-formedness on the assumption
that ElementTree's parse method did that behind the scenes. Is that
not correct?

(I didn't see any specifics on that subject in the docs:
http://docs.python.org/library/xml.etree.elementtree.html)

> But most importantly, you can divide the rules where you say "if the data
> looks like XXXX" the file is rejected.   Versus "if the data looks like
> YYYY, we'll pretend it's actually ZZZZ, and keep going.  An example of that
> last might be what to do if somebody specifies March 35.  You might just
> pretend March 31, and keep going.

Ok, so if I'm understanding -- I should convert invalid data to
sensible defaults where possible (like setting blank fields to 0);
otherwise if the data is clearly invalid and the default is
unknowable, I should flag the field for editing, deletion or some
other type of handling.