[Tutor] the art of testing

[Serdar Tumgoren]

> I'm not really sure where you are going with this? This looks like a
> data specification, but you said the data is poorly specified and not
> under your control. So is this a specification of a data validator?
>
The short answer -- yes, these are specs for a data validator.

And I should have been more specific about my problem domain. I'm
cobbling together a specification using various government manuals and
a *very* limited data definition.

For instance, the agency states that a lobbyist's status must be
either active (0), terminated (1) or administratively terminated (2)
or undetermined (3). So I know the expected inputs for that field.
However, the agency does not validate that data and it's possible for
that field to be blank or even contain gobbledygook strings such as a
'<Enter Lobbyist Status>' (residue from software built atop the
agency's automated filing service).

In other cases, based on working with the raw data, I've ascertained
that every Filing has at least a unique ID, and seems to have a Year,
etc. So it's a mish-mash of pre-defined "specs" (as best as I can
ascertain from the government), and patterns I'm discerning in the
data.

>
> Yes...but I'm not really clear what it is you want to test. What does
> your code do? What if a Filing does not have a 'Type' attribute?
>
At this stage, I'm just trying to perform some basic validation on the input.

'Type' is an attribute that I'd expect every filing to contain (and if
it does not, my code would have to log the record for human review).