Hi, I would like to override the DateTime.DateTime class within my functional tests. I have tried mocking (via mocker) and injecting the subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this? Thanks in advance, Tim
On Mon, Mar 23, 2009 at 06:21, Tim Knapp <duffyd@kokorice.org> wrote:
Hi,
I would like to override the DateTime.DateTime class within my functional tests.
I have tried mocking (via mocker) and injecting the
subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this?
What is the particular usecase? Zope has a very strong dependency from DateTime in various places. So there is almost no compatible way for getting rid of it or for replacing it. So why? -aj P.S. we don't like cross-postings - posting to one list is enough
On Mon, 2009-03-23 at 06:25 +0100, Andreas Jung wrote:
On Mon, Mar 23, 2009 at 06:21, Tim Knapp <duffyd@kokorice.org> wrote: Hi,
I would like to override the DateTime.DateTime class within my functional tests. I have tried mocking (via mocker) and injecting the
subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this?
What is the particular usecase?
I have applications that come into the system and fall into an invoicing period based on the 'created' index. I've managed to override the datetime in all my tests except in the 'created' index, which is recording the 'actual' date time. One option is patching the 'created' method in Archetypes/ExtensibleMetadata.py, which is what I'm favouring at the moment.
Zope has a very strong dependency from DateTime in various places. So there is almost no compatible way for getting rid of it or for replacing it. So why?
This is only in my tests as noted above.
-aj
-Tim
P.S. we don't like cross-postings - posting to one list is enough
Yeah, sorry about that. I am aware of this but wasn't entirely sure which list was best given that DateTime is a Zope module but is used heavily in Plone. I'll stick to the Zope list for questions of this nature from now on :)
Tim Knapp wrote:
I would like to override the DateTime.DateTime class within my functional tests. I have tried mocking (via mocker) and injecting the subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this?
You should take a look at testfixtures ;-) http://pypi.python.org/pypi/testfixtures Specifically, the @replace decorator for one test or the Replacer (to use in setUp and tearDown) NB: Make sure you replace it in the module where's *used*, not the module where it comes from... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi Chris, On Mon, 2009-03-23 at 12:45 +0000, Chris Withers wrote:
Tim Knapp wrote:
I would like to override the DateTime.DateTime class within my functional tests. I have tried mocking (via mocker) and injecting the subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this?
You should take a look at testfixtures ;-)
http://pypi.python.org/pypi/testfixtures
Specifically, the @replace decorator for one test or the Replacer (to use in setUp and tearDown)
NB: Make sure you replace it in the module where's *used*, not the module where it comes from...
Thanks. One thing, though, it appears that testfixtures requires python 2.5 as it tries to import functools that was introduced in python 2.5. /me carries on trying to get it going :) -Tim
cheers,
Chris
Tim Knapp wrote:
Thanks. One thing, though, it appears that testfixtures requires python 2.5 as it tries to import functools that was introduced in python 2.5.
/me carries on trying to get it going :)
Indeed, guess you'll have to go for Zope 2.12 :-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Tim Knapp wrote at 2009-3-23 18:21 +1300:
I would like to override the DateTime.DateTime class within my functional tests. I have tried mocking (via mocker) and injecting the subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this?
"import DateTime; DateTime=<myDateTimeClass>" should be able to replace the "DateTime" class -- sometimes. Be aware, however, that this replacing takes effect only after your assignment. Modules that already have imported the "DateTime" class will not be affected. -- Dieter
On Wed, 2009-03-25 at 21:20 +0100, Dieter Maurer wrote:
Tim Knapp wrote at 2009-3-23 18:21 +1300:
I would like to override the DateTime.DateTime class within my functional tests. I have tried mocking (via mocker) and injecting the subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this?
"import DateTime; DateTime=<myDateTimeClass>" should be able to replace the "DateTime" class -- sometimes.
Be aware, however, that this replacing takes effect only after your assignment. Modules that already have imported the "DateTime" class will not be affected.
Thanks, yeah that was what I thought. I tried to do it in the _setup method of PloneTestCase, which theoretically gets called before the instance is runup but maybe not. Didn't seem to affect the Zope instance itself anyway. -Tim
Tim Knapp, on 2009-03-26:
On Wed, 2009-03-25 at 21:20 +0100, Dieter Maurer wrote:
Tim Knapp wrote at 2009-3-23 18:21 +1300:
I would like to override the DateTime.DateTime class within my functional tests. I have tried mocking (via mocker) and injecting the subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this?
"import DateTime; DateTime=<myDateTimeClass>" should be able to replace the "DateTime" class -- sometimes.
Be aware, however, that this replacing takes effect only after your assignment. Modules that already have imported the "DateTime" class will not be affected.
Thanks, yeah that was what I thought. I tried to do it in the _setup method of PloneTestCase, which theoretically gets called before the instance is runup but maybe not. Didn't seem to affect the Zope instance itself anyway.
A few years ago at Zest Software we needed a patch (for Archetypes I think) and hit the same problem that our product was too late in the startup process to have enough influence. So we put the patch in a product called (Products.)AAAPatch; affectionately called triple A patch. :-) Due to the three A-s at the beginning it was virtually guaranteed to be the first product to load. -- Maurits van Rees | http://maurits.vanrees.org/ Work | http://zestsoftware.nl/ "This is your day, don't let them take it away." [Barlow Girl]
On Thu, 2009-03-26 at 09:16 +0000, Maurits van Rees wrote:
Tim Knapp, on 2009-03-26:
On Wed, 2009-03-25 at 21:20 +0100, Dieter Maurer wrote:
Tim Knapp wrote at 2009-3-23 18:21 +1300:
I would like to override the DateTime.DateTime class within my functional tests. I have tried mocking (via mocker) and injecting the subclassed DateTime class into sys.modules (results in a TraversalError). The fartherest I've gotten is to set DateTime.DateTime = MySubclassedDateTime in my tests.py, which does work for the code 'within' the package(s) I'm testing but all the Zope core code (i.e. the instance created within PloneTestCase) is still referencing the global DateTime module. Has anyone successfully done this?
"import DateTime; DateTime=<myDateTimeClass>" should be able to replace the "DateTime" class -- sometimes.
Be aware, however, that this replacing takes effect only after your assignment. Modules that already have imported the "DateTime" class will not be affected.
Thanks, yeah that was what I thought. I tried to do it in the _setup method of PloneTestCase, which theoretically gets called before the instance is runup but maybe not. Didn't seem to affect the Zope instance itself anyway.
A few years ago at Zest Software we needed a patch (for Archetypes I think) and hit the same problem that our product was too late in the startup process to have enough influence. So we put the patch in a product called (Products.)AAAPatch; affectionately called triple A patch. :-) Due to the three A-s at the beginning it was virtually guaranteed to be the first product to load.
Awesome, I'll give it a go and report back. Thanks, Tim
Dieter Maurer wrote:
Be aware, however, that this replacing takes effect only after your assignment. Modules that already have imported the "DateTime" class will not be affected.
Yes, but you can replace them in the same way... Just make sure you wrap in a try/finally so you un-replace no matter what happens... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (5)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Maurits van Rees -
Tim Knapp