[Grok-dev] Re: Suggested contents for a skeleton functional doctest
faassen at startifact.com
Wed Aug 15 11:25:39 EDT 2007
Tres Seaver wrote:
>> 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. :)
>> 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.
More information about the Grok-dev