-----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----- _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
