> 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
Serdar Tumgoren 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 nightmar
On Tue, Dec 15, 2009 at 8:05 PM, Serdar Tumgoren wrote:
> 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
>> p
> 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 n
On Tue, Dec 15, 2009 at 5:56 PM, Serdar Tumgoren wrote:
> Hi everyone,
>
> To continue on the popular topic of unit tests, I was wondering if
> it's generally preferable to use a single unit test or a series of
> unit tests when testing against a regex pattern.
>
> In my specific case, I started o
Hi everyone,
To continue on the popular topic of unit tests, I was wondering if
it's generally preferable to use a single unit test or a series of
unit tests when testing against a regex pattern.
In my specific case, I started out with a single test that contained a
(growing) list of bad input da