[Mailman-Developers] Killing off Pipermail and the effects on scrubbing in Mailman 3

[Andrea Crotti]

On 03/19/2012 11:25 AM, Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On Mar 17, 2012, at 04:43 PM, Mark Sapiro wrote:
>
>> Next step for me may be to learn more about how the unittests fit
>> within their framework so I can create some.
> It's *relatively* simple.  Essentially all unittests live in a test_foo.py
> module inside a tests/ directory (which has an __init__.py so it's a
> package).  I generally name unittest.TestCase subclasses as TestFoo and
> individual tests inside there as test_foo() methods.  There are lots of
> examples spread throughout.  It's only a little extra work if you have to
> create a new tests/ subdirectory or test_foo.py module, but again, it should
> be pretty straightforward.
>
> These all get auto-discovered by the zope.testing framework, so there's
> nothing else necessary to hook it all up.  The one other tricky thing is the
> layers, which are a zope.testing mechanism to share more generic resources
> among a suite of tests.  E.g. if you need the rest server to be started, you'd
> use the RESTLayer (see mailman.testing.layers for what's currently defined).
> To enable a layer, you just need to set the `layer` attribute of the TestFoo
> class.  Almost all the tests will require at least the ConfigLayer since that
> brings up the Zope component architecture, connfiguration system, etc.
>
> zope.testing is a bit weird here because the normal rules of subclasses don't
> actually apply.  E.g. the LMTPLayer derives from ConfigLayer which derives
> from MockAndMonkeyLayer.  All the appropriate setUp()s get called by
> zope.testing so you don't need to up-call explicitly in the layer class.  Yes,
> this kind of sucks since it's magical, and it's one reason why eventually I'd
> like to switch to something like testresources and a more sane testing
> framework, but that's a lot of effort for little immediate value.
>
> Note that doctests are all set up in test_documentation.py so they're not
> really all that special.
>
>

Just as a suggestion, it would be nice to have a few lines in the 
documentation about this, something
like you just explained would be already quite good, since it's not so 
clear by just looking at the code..

Cheers,
Andrea