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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> Hey,
> 
> On 8/15/07, Tres Seaver <tseaver at palladion.com> wrote:
> [snip]
>>> Grok is as test-hostile as a normal Zope 3 application is: quite a
>>> bit. It's not *more* test-hostile though.
>> It is *more* hostile because standard practice to date for Grok
>> applications has been to leave the application programmer to write her
>> own tests, without benefit of examples which make it clear how to do
>> test setup in Grok (as opposed to "classic" Zope3 apps).  The culture
>> for the Grok *application* developer has thus been hostile, because it
>> is both hard and not encouraged to write tests.
> 
> 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).

> Again, Zope 3 tests and Grok tests are almost *exactly* the same. The
> one exception I can think of  is that in grok, you can use the 'grok'
> function in your doctest to grok a module or package. That's it,
> though.
> 
> The confusion kicks in when people examine the *core* Grok tests,
> which are set up in a peculiar way to let Grok test the grokking
> procedure. With Martian, this is actually mostly not necessary
> anymore, but the tests haven't been rewritten yet. I haven't found
> Grok's strategy of use in my own code, but of course people naturally
> look at the core tests to see how to do their own tests, and get the
> wrong clues.
> 
> [snip]
>>> I think the impulse when confronted with complicated, crufty code that
>>> is repeated over and over again should *not* be to generate it. It
>>> should be to investigate whether we can make it far less code. Test
>>> setup code is a prime example of crufty code that is repeated over and
>>> over again.
>> - -1.  Trying to make test setup code re-usable is more likely to make it
>> unreadable.  The best tests do the *absolute minimum required for this
>> test*;  doing more because somebody wrote some "reusable" setup code
>> tends to obscure the intent of the given test.
> 
> I'm trying to make it *go away* as much as possible. I don't want to
> have to remember how to do this ever again:
> 
>   (in a module called ftests.py or a package ftests)
> 
>   import unittest
> 
>   from zope.app.testing.functional import FunctionalDocFileSuite
>   from ... import FunctionalLayer
> 
>   def test_suite():
>      globs = {}
>      foo = FunctionalDocFileSuite(
>           '../foo.txt',
>           globs = globs,
>           )
>       foo.layer = FunctionalLayer
>       return unittest.TestSuite([foo])
> 
> 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.
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).

>> 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. 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.



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGwxOq+gerLs4ltQ4RAsWYAJ9VtsMco80aIqA9hjMth4SML4py0ACcDqe+
kQJAvBs7y1hf40cozLz7iiI=
=vDAv
-----END PGP SIGNATURE-----