Skip to content.

plope

Personal tools
You are here: Home » Members » chrism's Home » Writing Bad Unit Tests » Test only what you write
 
 

Comment

Above in this comment thread: Writing Bad Unit Tests » Unit, integration, mock

Test only what you write

Posted by tseaver at 2008-05-29 07:45 AM
> As Alex points out, PloneTestCase is about integration testing.
> The "official" Plone testing tutorial even says so -
> http://plone.org/documentation/tutorial/testing.

Try running just the unit tests for *any* stock Plone product:
you will see the PTC / ZTC spew ("Installing product Foo"). The
Plone tests still can't be run as a whole reliably, either.

> Quite often, integration tests are more important in Plone. The
> first tests you write tends to be:
>
> - does the product install?
> - did it set up the necessary bits (new workflows, say)?
> - can I create an object of this type in the intended location?
>
> It's quite hard to mock up the underlying bits of Zope and Plone
> in order to properly write unit test for things like Archetypes
> objects. For declarative GenericSetup stuff, say, it's
> impossible, and integration tests are the only meaningful way of
> testing.

You don't need to test code you don't write: if your "product
installation" is just types, skins, and workflows in a GS
profile, you don't need to automate testing it: that code is
already tested elsewhere.

If you are writing your own GS handlers which parse such files
(which nobody is doing in Ploneland: see my 'plone_gs' product)
then you should test those handlers (note that I skimped on those
tests during my Memorial Day weekend jag). those tests should *not*
require creating a Plone site, however -- they should use minimal
mock objects.