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

Framework-Team mailing list

Reply via email to