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

[Barry Warsaw]

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

>Also, I need to figure out a better development platform for Windows
>boxes. I had a perfect opportunity to scrap Windows all together when
>I had to recover from a hard drive crash on my main development box
>last year, but the dice fell the wrong way on that one.

There are lots of options here.  As mentioned, virtualbox should be a good
option, and you can probably use something like wubi to create an Ubuntu
desktop running along side Windows.  Of course, all the Linuxes should give
you a way to dual-boot your Windows machine if you're so inclined.  You may
even be able to boot off a USB drive or stick, though that will be slower.
Commercial options such as VMware are also a possibility, though of course you
should try the free options first. :)

>Maybe I can organize a sprint at the next PyCon - Migrating to Linux
>and killing Windows one PC at a time.

Definitely. :)

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPZxexAAoJEBJutWOnSwa/jlQQAKqzGaL5Vrnm5vS8+NSlN+LH
gY/Gyh/aT8F4V6IYd3Hn47kPMtdMPv6m+FNhSTOGkwf1EU1UtPgNvkcYUNuVsHBe
A9Bh04DDk0t5S1WOdcKBSdkwt65YR3yNkvsiCZQpOXD4xDF4EDlSRwNTjtGk6ze7
84xBUL5DXJiO1L5OxBsZusYlR4vpO80AwCszil3uon9oDQIxsHuXvPfVwjJM8CfN
hFf3Rq7LePLbOO0uFNLxsDxMyRZx0wrN/vg+2H81bnLNdheaqlmRjoZn2TkFZmTb
eYN+XeFW9l2jlGgYfQAm8R5e+mNhE+a3HG7LwO2IyYn8JzR+YTFQeiR91XdOFYrt
OPfMrXbUaRAb6QEwwWJY2HmbqIiihgFOPtmSBSRcIoiU/cWjC6LbajZN8QV24xhq
yTrbkBxZBTGPPQ7tgd05bb/PYlqdWCRoXeL8zlbcDK98MFzPgfBMfmHqWObPd+8E
q49pDoeDUlhW+SmhfTOqM3zQvuolIu6WYDTcTeIWYLzMsjT3pDJ6R1NIw4jNGmtl
TqLYL+WuUzBXyNfGD234C2VnJscVyJLFduew2pig6dFG0MX9gAN/zTI3i8wZDlUC
xDKDagCZ7uSNzjVEDQLzoZmrs3EzuPvCY5h4kzlVObUiKBvg8ALPEV8MJS6M8QDj
IeBbG8Iniz01AoBaixZ1
=rxit
-----END PGP SIGNATURE-----