[TIP] Test coverage and parsing.

Olemis Lang olemis at gmail.com
Mon Oct 5 08:00:19 PDT 2009

On Mon, Oct 5, 2009 at 9:39 AM, Olemis Lang <olemis at gmail.com> wrote:
> On Tue, Jul 28, 2009 at 11:56 AM, Grig Gheorghiu
> <grig.gheorghiu at gmail.com> wrote:
>> On Tue, Jul 28, 2009 at 9:00 AM, Olemis Lang<olemis at gmail.com> wrote:
>> For your scenario, I think you need a combination of well thought out
>> test data (which like you said should cover both corner cases and
>> cases which should trigger errors/exceptions)

IMO, what I need is more close to this approach ...

>> and traditional test
>> coverage.

... than traditional test coverage. Nonetheless, both could be helpful.

Ouch ! I forgot to mention something

> Well ... something like that. What I'd like to do (at least in my dreams) is :

     - I'd like both functional and robustness test cases (i.e. data)

The way I see it, priority in this case is to *generate* some kind of
black box functional + robustness test cases for a SQL engine . Once
it will be available, white box functional + robustness test cases may
be written using traditional test coverage techniques .



Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -

More information about the testing-in-python mailing list