On 07/07/2010 21:33, Brett Cannon wrote:
On Wed, Jul 7, 2010 at 13:16, Alexander Belopolsky
<alexander.belopol...@gmail.com> wrote:
On Wed, Jul 7, 2010 at 3:45 PM, Brett Cannon<br...@python.org> wrote:
On Wed, Jul 7, 2010 at 08:29, Alexander Belopolsky
<alexander.belopol...@gmail.com> wrote:
..
For datetime.py this approach presents several problems:
1. replacing datetime with self.module.datetime everywhere can get
messy quickly.
2. There are test classes defined at the test_datetime module level
that subclass from datetime classes. The self.module is not available
at the module level. These should probably be moved to setUp()
methods and attached to test case self.
3. If #2 is resolved by moving definitions inside functions, the
classes will become unpickleable and pickle tests will break. Some
hackery involving injecting these classes into __main__ or module
globals may be required.
So I have been thinking about this about how to possibly make this
standard test scaffolding a little cleaner. I think a class decorator
might do the trick. If you had all test methods take a module argument
you could pass in the module that should be used to test. Then you
simply rename test_* to _test_*, create test_*_(c|py), and then have
those methods call their _test_* equivalents with the proper module to
test. You could even make this generic by having the keyword arguments
to the decorator by what the test suffix is named.
Hmm, I've been playing with the idea of using a metaclass to do
essentially the same, but a class decorator may be a simpler solution.
I still don't see how this address #1, though. In the ideal world,
I would like not to touch the body of test_* methods. These methods,
however are written assuming from datetime import date, time,
datetime, tzinfo, etc at the top of test_datetime.py. Even if the
decorator will call _test_* with six additional arguments named date,
time, datetime, tzinfo, etc, it will not work because by the time
decorator (or even metaclass machinery) gets to operate, these names
are already resolved as globals.
Well, I personally would call that bad form to import those classes
explicitly, but that's just me. You will simply need to make them work
off of the module object. There is nothing wrong with "cleaning up"
the tests as part of your work; the tests code should not be enshrined
as perfect.
Yep - each test should take the module under test (either in C or
Python) as the parameter and used classes / functions as attributes off
the module object.
Using a class decorator to duplicate each _test_ into two test_* methods
sounds like a good approach.
Michael
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of
your employer, to release me from all obligations and waivers arising from any
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in perpetuity, without
prejudice to my ongoing rights and privileges. You further represent that you
have the authority to release me from any BOGUS AGREEMENTS on behalf of your
employer.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
