[Tutor] the art of testing
Dave Angel
davea at ieee.org
Tue Nov 24 23:15:24 CET 2009
Serdar Tumgoren wrote:
> Lie and Kent,
>
> Thanks for the quick replies.
>
> I've started writing some "requirements", and combined with your
> advice, am starting to feel a bit more confident on how to approach
> this project.
>
> Below is an excerpt of my requirements -- basically what I've learned
> from reviewing the raw data using ElementTree at the command line.
>
> Are these the types of "requirements" that are appropriate for the
> problem at hand? Or am I not quite hitting the mark for the data
> validation angle?
>
> I figured once I write down these low-level rules about my input, I
> can start coding up the test cases...Is that correct?
>
> << requirements snippet>>
>
> Root node of every XML file is PublicFiling
> Every PublicFiling node must contain at least one Filing node
> Every Filing must contain 'Type' attribute
> Every Filing must contain 'Year' attribute, etc.
> Filing node must be either a Registration or activity Report
> Filing is a Registration when 'Type' attribute equals 'Registration'
> or 'Registration Amendment'
> Registration must not have an 'Amount' attribute
> Registration must not have an 'is_state_or_local_attrib'
>
> << end requirements>>
>
>
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.
In addition, you want to state just how flexible each field is. You
mentioned booleans could be 0, 1, blank, ... You might want ranges on
numerics, or validation on specific fields such as Year, month, day,
where if the month is 2, the day cannot be 30.
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.
Don't forget that errors and warnings for the input data need to be
output in a parseable form, at least if you expect more than one or two
cases per run.
DaveA
More information about the Tutor
mailing list