On Jul 27, 2010, at 05:56 PM, Yaroslav Halchenko wrote: >On Thu, 22 Jul 2010, Barry Warsaw wrote: >> In my copious spare time <wink>, I'm working on code, documentation, >> and infrastructure to make this the preferred way of testing Python >> modules and applications. You don't *have* to conform, but we'll >> put out big carrots for you if you do. > >do you have somewhere any documentation available on this >infrastructure so we could point upstreams to follow?
I don't at the moment, but I really need to put such a wiki page together. It's just gotten pushed down on the stack. :( >are you recommending nose as the testing framework? what internal >organization of the modules to support it do you recommend... i.e. in a few >modules I saw (and we somewhat adopted in our projects) having I'm currently in favor of unittest2, but nose has some nice features. When unit2's plugin architecture is done, I think that'll probably be the way I want to go. >project/data -- minimalistic data sets (if) necessary for >testing/examples project/testing -- tools >project/tests -- actual unittests which rely on project.testing It's an open question, and I know there are a million different ways people structure their tests! I generally have project/testing for support code, project/testing/data for test data sets, project/tests for unittests and project/docs for doctests. >alternative strategy is to take advantage of nose discovery allows >to keep unittests closer to respective code, so /tests is not needed >any longer... True. I like separating my tests into submodules, and I don't personally like in-docstring doctests, so I'm biased toward those decisions. -Barry
signature.asc
Description: PGP signature
