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 future. 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. Thoughts? Cheers, Martin _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
