[Python-ideas] Add links in manual to test_modules.

[Westley Martínez]

On Sat, 2011-03-19 at 09:22 -0700, Guido van Rossum wrote:
> On Fri, Mar 18, 2011 at 11:45 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> > Nick Coghlan wrote:
> >>
> >> Ick, no.
> >>
> >> We do all sorts of dodgy stuff in our test suite to stress
> >> implementations, probe obscure corner cases, double up on checks based
> >> on where and when bugs happened to be reported. Large parts of it are
> >> written to make the tests easier to write, not because they reflect
> >> any kind of idiomatic code, or good ways of doing things in a real
> >> application.
> >
> > But surely a test suite counts as a real application? It's likely to be
> > bigger than the "actual" application or library, it still needs to be
> > maintained, and is more likely to have bugs (on account of there being no
> > test suite for the tests).
> >
> > Speaking for myself, I find code reuse and design of my test suites to be
> > one of the harder parts of writing code. Perhaps I'd learn something from
> > the Python tests, even if only "everyone has trouble writing good
> > unit-tests" *wink*
> >
> > As I see it, the main benefit of Terry's suggestion is that it may encourage
> > developers to write new tests for the standard library, or to refactor the
> > existing tests. +0.5 from me.
> 
> I'm with Nick. Tests (at least the ones we have for the standard
> library) are rarely any good as example code for the modules being
> tested. They may be great if you want to learn to write tests or if
> you want to contribute to the stdlib, but they are easy enough to
> find. Linking them from the docs is sending people to a body of code
> that most people should never peruse.
> 
> The one exception is that the tests can show language/library lawyers
> how something is supposed to behave in more detail than docs, without
> having to actually read the source. But again that's pretty advanced
> and the people interested in that stuff know where to go.
> 
I agree with Nick and Guido. Tests are essentially source code, but
instead of creating functionality it is testing functionality, and like
source code may not be written ideally.