[Tutor] another unit-testing question: regex testing

[Serdar Tumgoren]

> I often use a list of test cases to drive a single test. Using a
> series of tests is just too painful compared to making a simple list
> of test cases.

I kinda suspected that but wasn't sure. These tests are for a REALLY
basic regex and I was having nightmares thinking how many tests would
be needed for a modestly more complex pattern. I'm leaning toward
collapsing the tests back into a single unit-test.  I should add,
however, that the process of breaking these out separately led me to
refine the regex and discover a few obvious tests I'd missed (e.g.
test for blank input or no input).

> The disadvantages to using a list of test cases:
> - it will die at the first failure, which may hide other failures
> - the default failure messages are generally not helpful - they won't
> necessarily tell you which test case failed.

That's the main benefit I noticed with the other approach.

I usually build a custom
> failure message and use the assertXxx() method that takes a message
> parameter. (In your case, you will have to use a try / catch with a
> fail() in the try block because assertRaises() doesn't take a msg
> parameter.)

Not sure I follow here. The try/catch should go in the unit test or
the code under test?

And finally, I was also wondering about testing classes and
subclasses. For instance, if I have an Office class and a subclass
Member, can I perform tests on any shared code (i.e. inherited by
Member) solely against the superclass? Are there any specific types of
tests that are standard for testing proper inheritance and other such
issues?

Would be happy to read up elsewhere if you all can point me to
resources. Just haven't stumbled into any examples yet on this
specific topic of testing subclasses relative to parent classes (Also,
I know it's slightly off-topic, so I'd be happy to start a different
thread if appropriate).

Regards,

Serdar