Hi team,

This weekend, I worked on plone.uuid and plone.app.uuid, part of PLIP
#10778 (which is now mostly implemented, by the way). These are both
quite simple packages. Obviously, both have tests.

When writing them, I wanted to use the new plone.testing /
plone.app.testing packages. However, I'm not sure whether this is
something we need to PLIP separately or not. Certainly, I think a
wholesale move away from PloneTestCase is infeasible for Plone 4.x.
However, for new packages, I'd like to use the cleaner, leaner "new"
packages. A few good reasons include:

* They make test runs slightly faster
* They are better documented
* They make it easier to make custom layers
* They provide better test isolation by not relying on global state
* They standardise test setup and patterns, e.g. how to use layers effectively
* They use the new Python 2.7 standard library unittest module (via unnittest2)

The main downside is possible confusion, since we can't deprecate
ZTC/PTC at the present time. They're also much younger and less well
tested, obviously, although they clearly draw their heritage from
ZopeTestCase and PloneTestCase, respectively.

I've got the tests to work with plain unittest.TestCase and
PloneTestCase, so there's no *pressing* need for this, but equally I'd
like these packages to be an example of "good practice". Right now, I
feel a bit iffy about using PloneTestCase, since I feel plone.testing
provides a better alternative that ought to become commonplace in the

So, we can either:

1) Stay with the status quo, and hope that
plone.testing/plone.app.testing become the standard for Plone 5. In
the meantime, people can use it in non-core packages only.
2) Use them as test dependencies, and let people choose how to set up
their own tests
3) Write a separate PLIP for the inclusion of these two packages into
our KGS (but not for the porting of all existing PTC tests, since
that'd be a pretty big task)

My preference is for option 2.


Framework-Team mailing list

Reply via email to