[Tutor] another unit-testing question: regex testing

[spir]

Serdar Tumgoren <zstumgoren at gmail.com> dixit:

> > 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).

I found existing test libs to be difficult to adapt to text matching/parsing/processing tasks. So I ended up writing my own testing utilities. But the context is different: it's for a custom matching library, with pattern objects for which testing tools are methods. Anyway, someone may find it interesting. There are two main tools:

* One method performs at test match of a given input against a given pattern (with a given method, for there are 'match', 'parse', 'findFirst', 'findAll', 'replace) and clearly prints out source/pattern/outcome (which can be failure). Also, this method catches & prints out exceptions, so that any number of trials can be chained in a hand-written testing func, & run as expected without stopping at first failure.
This is the base method for my tests at develoment time.

* Another tool is rather used for lasting test suites, with maintenance in mind.
A first method builds a 'testsuiteDict' from a set of source strings for a given pattern (again failures included). The outcome is a plain python dict with (source:result) pairs. Depending on the case, results are (like python repr()) re-readible object representations, or any kind of reliable string representations. The aim is that they can be compared to later results obtained from running the same test suite.
Precisely, the second method 'testSuite' is passed a pattern and a previously built test-suite dict, runs the trials for the list of source strings and checks the outcomes against the previously recorded results. This provides a base for secure long-term maintenance.
But testsuiteDict can also be used alone simply to run a test suite for a given pattern: in addition to returning the dict, it also prints it in clear format (but still grammatically correct to read it back), so one can easily chack the series of source:result pairs. It's a kind of compact form of the first method above, but for a single pattern.


Denis
________________________________

la vita e estrany

http://spir.wikidot.com/