Re: XML and unit testing

[David Brownell <david-b@pacbell.net>]

Another testing framework to think about is Mauve.

I'm most familiar with separate tests, plugging into some sort of testing
framework or harness.  The harness automates running lots of tests,
setting each one up and collecting results (pass/fail/expected/...) as
well as (important!) organizing unexpected results for analysis.  What
you want is a quick report that says highlights expected and unexpected
results; when you get to even a few hundred tests, it's impossible to be
looking at each individual test on any regular basis.  (Sadly, negative
tests tend to always need that attention ... positive tests are easier,
but applications break just as badly when the APIs fail in the wrong
way as when they fail at the wrong time!)

API specs need to be written to be testable.  Some of the "APIs" I
see floating around are basically "not testable" because of size, and
exposing too many internals.  Once a spec is testable, then a
surprisingly large number of tests need to be written.

I think the deep/shallow copy sorts of issues you mentioned are each
going to need individual tests.


> I doubt I'm the only person dealing with these kinds of issues on
> xml-dev, but I still wonder if anyone's really explored how unit testing
> and XML fit together.  Validation is something that comes naturally to
> XML, but it's a different kind of testing than the finer-grained object
> unit testing approach I'm looking for.

There's also "regression testing", which you can think of as unit testing
that's maintained in sync with the software so that you can know updates
aren't going to break things.

- Dave