[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