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

Tres Seaver tseaver at palladion.com
Wed Aug 15 01:16:53 EDT 2007

Hash: SHA1

Martijn Faassen wrote:
> Hey,
> On 8/14/07, Tres Seaver <tseaver at palladion.com> wrote:
>> 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 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.

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

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

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.

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


More information about the Grok-dev mailing list