[TIP] Test coverage and parsing.
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
... 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/
Nabble - Trac Users - Coupling trac and symfony framework -
More information about the testing-in-python