[Grok-dev] Re: Suggested contents for a skeleton functional doctest

[Martijn Faassen]

Tres Seaver wrote:
[snip]
>> Sure, we lack documentation on how to set up tests. So do classic Zope
>> 3 apps. :)
> 
> Both Zope3 books describe clearly how to write tests for Zope3
> applications.  *Every* Zope3 package has examples (some better, some worse).

Yup, and that documentation does apply to Grok as well. :)

[snip]
>> Do I understand you correctly and are you saying that this code helps
>> you understand the intent of the test?
> 
> No, but I don't mind its presence, either, compared to trying to figure
> out some majyk incantation to get my tests to run without an example.

I just want the example to be more compact and less crufty.

> Adding cruft to the testcase code itself to "help" some majyk framework
> "discover" the test is much worse:  I prefer to *tell* the framework
> what tests to run (and particularly, I don't want to have to jump
> through hoops to keep the framework from running some base-class testcase).

Grok has a special hoop there; you can use grok.baseclass(). :)

I'd prefer to avoid the situation where my code has tests that are never 
actually being run. It may take quite a while for the reader of the code 
to figure out that the tests that seem to pass are actually never 
executed in the first place.

>>> More typing *may* be the greater evil in *application* code;  in test
>>> code, it tends to be the lesser evil, in my experience.  Cleverness,
>>> majyk, and frameworks should be kept as far away from test code as possible.
>> Are we really talking about the same thing? I'm not talking about code
>> in tests, but I'm talking about test setup code like the stuff above.
>> If you are talking about that too, then we can safely say we disagree
>> very much.

So were we talking about the same thing?

>> If I see the same repeated cruft (that I can't even
>> remember) over and over again, I want to make it go away. I think
>> there's absolutely no benefit to make everybody remember a ton of
>> imports and obscure dances just so they can set up a functional doc
>> test. To me, it's a sign of a weakness in the testing API that so much
>> work is needed. There are better ways to do things.
> 
> If it is generated, then nobody needs to remember it either.  I don't
> share your utter aversion to generating boilerplate, in such a case.

I can understand code generators that actually generate something useful 
from another representation of the information: classes from a UML 
diagram, for instance.

I don't understand code generators that generate the same thing over and 
over again, as it's just too annoying to set it up manually. I can 
accept that in some situations it has to be done, but I'd like it to be 
the last impulse towards a solution, after other ways to solve the 
underlying problems have been explored. I don't think that in the case 
of test setup code we've exhausted our explorations yet.

Regards,

Martijn