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

[Martijn Faassen]

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

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?

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

Regards,

Martijn