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

Martijn Faassen faassen at startifact.com
Tue Aug 14 16:04:18 EDT 2007


Hey,

On 8/14/07, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Martijn Faassen wrote:
> > Luciano Ramalho wrote:
> >> A fresh grokproject generated sample app passes the doctest below the ###.
> >>
> >> The doctest shows basic operation of the test browser, and also how to
> >> instantiate and exercise the app.
> >>
> >> I think including a test like this in grokproject will make it much
> >> easier for beginning grok users to get in the habit of writing
> >> functional tests.
> >
> > This is far too much cruft for me. The risk is high that this will be in
> > people's projects forever, broken, distracting. Let's create a document
> > that spells out what to do instead, first.
>
> It is a truism in TDD that "the first test is the hardest."  I can see
> real value in generating the first one for a grok project, even if it
> does not test "real" application behavior:  perhaps it merely tests that
> the application object implements an interface, or something.
>
> Grok is notably test-hostile, at the moment, perhaps becuase of the "low
> barrier to entry" mantra.  Testing code *is* tedious to write, but
> without it, grok-based projects are going to turn into nighbmares as
> they evolve beyond toy stage.

Grok is as test-hostile as a normal Zope 3 application is: quite a
bit. It's not *more* test-hostile though.

It's possibly even somewhat *less* test hostile for people writing
(non-functional) unit tests, as it allows people to grok a module or a
package from within a unit test instead of having to roll the
registrations by hand (which is typically done for ZCML based unit
tests).

It's just that the test setup work in standard Zope 3 is:

* obscure - you need to know what you're doing and there's no easy
document that tells you what to do.

* too crufty - there's too much code to write to set up tests. I've
set up a test infrastructure for lots of Zope 3 applications and
libraries now, and I keep having to look up how to do it. I just can't
remember it.

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.

Regards,

Martijn


More information about the Grok-dev mailing list