[Framework-Team] PLIP 20144

Johannes Raggam raggam-nl at adm.at
Tue Dec 9 12:39:31 UTC 2014


On Tue, 2014-12-09 at 12:10 +0100, Timo Stollenwerk wrote:
> Am 09.12.2014 um 11:16 schrieb Philip Bauer:
> > 1. Tests: I realized that most test do not use the dexterity types at all. It might be that we miss some problems because of that. I changed the tests for plone.app.contentmenu to test both AT and DX (https://github.com/plone/plone.app.contentmenu/pull/8) but the test-setup is a little cumbersome. We need a canonical test-setup to test both frameworks otherwise all packages do it differently and future developers will a good reason to hate us. 
> 
> Thanks for bringing this up! :)

yep.

> The initial idea was to move all tests to use Dexterity types or the
> p.a.contenttypes fixture (if necessary). I don't think a generic test
> fixture that supports both AT and DX is possible.
> 
> Tests with tons of if/else statements for DX/AT are a horrible idea in
> my optinion. They are a nightmare to maintain, to debug and really hard
> to understand.

In plone.app.event until 1.2 there is a generic test suite for
Archetypes and Dexterity. I think, this approach was quite elegant:

In
https://github.com/plone/plone.app.event/blob/1.2.x/plone/app/event/tests/base_setup.py#L32 there is an ``AbstractSampleDataEvents``, which creates a basic set of content to test with. The abstract ``event_factory`` method was overridden by AT or DX based unit test classes, like here:

https://github.com/plone/plone.app.event/blob/1.2.x/plone/app/event/tests/test_event_view.py#L13

You see, ``TestEventViewDX`` defines all tests cases and the concrete
implementation of ``event_factory`` and uses an DX test layer.
``TestEventViewAT`` below just subclasses the DX one, overrides
``event_factory`` and uses an AT layer:
https://github.com/plone/plone.app.event/blob/1.2.x/plone/app/event/tests/test_event_view.py#L63

So both unit tests classes run the same the test cases.

That's possible, because there are AT and DX content type
accessors/wrappers, which unify ``set`` and ``get`` access to those
types.

Initially this was a proof of concept on how to support both Archetypes
and Dexterity in one package without duplicating code. It works quite
well! But we were removing the Archetypes based code from
plone.app.event 2.0, since this release is Dexterity only.

To the question on what to do with our Plone tests: Instead of creating
accessor methods for AT and DX content types, I think it's better to
rewrite for Dexterity only and move the Archetypes test classes into the
ATContentTypes package before.

Johannes


> Therefore, even though it is not perfect, I think we should stick with
> the approach to test against Dexterity only. For some packages it might
> be necessary to actually test both, but those should be the exception
> from the rule. Most packages just need "some" content object and it does
> not really matter if it is a DX or AT object.
> 
> One problem I see with that approach is that the p.a.contenttypes
> fixture, that most packages use, might be a bit too heavy. If
> p.a.contenttypes becomes the de-factor test layer we have to make sure
> that we keep it lightweight (because it is incredibly hard to change a
> test fixture that is used by so many packages later and it is generally
> a bad practice to put stuff into the main fixture if they are only
> needed for a couple of tests).
> 
> Therefore we should have a close look at the p.a.contenttypes and
> p.a.event test fixture and make sure they are as lightweight as possible.
> 
> I agree that we need to write down some guidelines for tests and that we
> have to work on that. Though, my priorities right now are the control
> panels, because they are blocking the Plone 5 beta release. If anybody
> wants to work on that I'm happy to help though!
> 
> Timo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20141209/4f77ffed/attachment.asc>


More information about the Framework-Team mailing list