[Python-ideas] [Brainstorm] Testing with Documented ABCs

Marcos Eliziario marcos.eliziario at gmail.com
Wed Nov 28 10:41:07 EST 2018


>
> In the end, you have to be rigorous when writing tests, and for most
> non-trivial functions it requires that you devise the distribution of
> input values depending on the implemented algorithm, not leave that
> distribution to a third-party library that knows nothing about your
> program.
>

Indeed.
But the great thing about the "hypothesis" tool is that it allows me to
somewhat automate the generation of sets of input values based on my
specific requirements derived from my knowledge of my program.
It allows me to think about what is the reasonable distribution of values
for each argument in a function by either using existing strategies, using
their arguments, combining and extending them, and them letting the tool do
the grunt work of running the test for lots of different equivalent classes
of argument values.
I think that as long as the tool user keeps what you said in mind and uses
the tool accordingly it can be a great helper, and probably even force the
average programmer to think more rigorously about the input values to be
tested, not to mention the whole class of trivial mistakes and
forgetfulness we are all bound to be subject when writing test cases.

Best,



Em qua, 28 de nov de 2018 às 12:18, Antoine Pitrou <solipsis at pitrou.net>
escreveu:

> On Tue, 27 Nov 2018 22:47:06 -0600
> Abe Dillon <abedillon at gmail.com> wrote:
> >
> > If we could figure out a cleaner syntax for defining invariants,
> > preconditions, and postconditions we'd be half-way to automated testing
> > UTOPIA! (ok, maybe I'm being a little over-zealous)
>
> I think utopia is the word here.  Fuzz testing can be useful, but it's
> not a replacement for manual testing of carefully selected values.
>
> Also, the idea that fuzz testing will automatically find edge cases in
> your code is idealistic.  It depends on the algorithm you've
> implemented and the distribution of values chosen by the tester.
> Showcasing trivially wrong examples (such as an addition function that
> always returns 0, or a tail function that doesn't return the tail)
> isn't very helpful for a real-world analysis, IMHO.
>
> In the end, you have to be rigorous when writing tests, and for most
> non-trivial functions it requires that you devise the distribution of
> input values depending on the implemented algorithm, not leave that
> distribution to a third-party library that knows nothing about your
> program.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Marcos Eliziário Santos
mobile/whatsapp/telegram: +55(21) 9-8027-0156
skype: marcos.eliziario at gmail.com
linked-in : https://www.linkedin.com/in/eliziario/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181128/cbb7a18e/attachment.html>


More information about the Python-ideas mailing list