[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