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

-- 
Regards,

Olemis.

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

Featured article:
Nabble - Trac Users - Coupling trac and symfony framework  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hlNmupEonF0/Coupling-trac-and-symfony-framework-td25431579.html



More information about the testing-in-python mailing list