Serdar Tumgoren <[email protected]> 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/
_______________________________________________
Tutor maillist  -  [email protected]
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Reply via email to