On 1 August 2010 23:27, Eric Steele <ems...@psu.edu> wrote: > On Aug 1, 2010, at 10:50 AM, Martin Aspeli wrote: >> 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 > > Nice work Martin. As you know, I'm already using this in a project and > absolutely loving it. I'm really excited to try some selenium testing now > that that last issue has been fixed. > > I think we do need to PLIP the inclusion of plone.testing/plone.app.testing > as a dependency. We ran into a similar issue with plone.app.registry and > z3c.form when considering plone.app.discussion for 4.0. The FWT wanted the > opportunity to give them an official review and also have the opportunity to > potentially declare them as current best practice for new features. > > I'd certainly love to see all core packages move to using > plone.testing/plone.app.testing (death to bin/alltests!), but I agree that > it'd be a huge undertaking. I'd like to propose a fourth option -- that we do > #3 above, but have the FWT vote on declaring that the current best practice > for new packages for 4.1 and beyond.
Sounds good. Once dev.plone.org stops looking like someone regurgitated a Plone 2 site all over it, I'll add a PLIP. ;) Martin _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
