[Zope3-dev] layers can't be new style classes?
Hi All, It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
IIRC you need @classmethod def setUp(cls): pass @classmethod def tearDown(cls): pass On 17. Okt 2006, at 12:30, Chris Withers wrote: It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? -- Anything that, in happening, causes something else to happen, causes something else to happen. --Douglas Adams ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Stefan H. Holek wrote: IIRC you need @classmethod def setUp(cls): pass @classmethod def tearDown(cls): pass Sorry, braino on my part. Yes, I have the @classmethod's and I still see the error: AttributeError: type object 'object' has no attribute 'setUp' cheers, Chris PS: Has anyone doen the work Philipp aludes to in his article to make ZopeTestCase a series of layers? -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: layers can't be new style classes?
Hi Chris. Look at z3c.sampledata.layer, I provide a testlayer there. Maybe you need to provide the __bases__! Jürgen Chris Withers wrote: Hi All, It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? cheers, Chris ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Chris Withers wrote: Now, related to this, say I have content objects X and Y, which are expensive to set up. I have LayerX which sets up a sample content object X, and LayerY which does the same for content object Y. This is fine for tests which need one or other content type, but how do I write tests which need both? Layers are ... layered. If your test base class has layer X and a test case subclass of that has layer Y, then it will set up X, run all the X tests, then setup Y and run all the Y and XY tests, then tear down Y and then X. I did this in Plone recently, but it completely escapes me where. Maybe I'll have an epiphany after lunch, but look at how the ZCML layer in PloneTestCase trunk works (it sets up all kinds of ZCML) and then try to derive a class from PloneTestCase (or your equivalent) and set layer = myLayer. Martin -- View this message in context: http://www.nabble.com/Test-Layers-tf2458447.html#a6853085 Sent from the Zope3 - dev mailing list archive at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Chris Withers wrote: Hi All, Am I right in assuming that there aren't any good narrative docs for test layers? This is obviously in the eye of the beholder. I'm sure the people who created narratives tried to do a good job. Perhaps you can do better. ... Now, related to this, say I have content objects X and Y, which are expensive to set up. I have LayerX which sets up a sample content object X, and LayerY which does the same for content object Y. This is fine for tests which need one or other content type, but how do I write tests which need both? You create a layer that extends both. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Martin Aspeli wrote: Layers are ... layered. If your test base class has layer X and a test case subclass of that has layer Y, then it will set up X, run all the X tests, then setup Y and run all the Y and XY tests, then tear down Y and then X. I didn't mention subclassing tests. Personally, I think that's evil... I did this in Plone recently, but it completely escapes me where. Maybe I'll have an epiphany after lunch, but look at how the ZCML layer in PloneTestCase trunk works (it sets up all kinds of ZCML) and then try to derive a class from PloneTestCase (or your equivalent) and set layer = myLayer. What layer(s) would the following test be executed in: class BaseX(TestCase): layer = 'X' class BaseY(TestCase): layer = 'Y' class SomeTests(BaseX,BaseY): def test_1(self): pass cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Chris Withers wrote: Hi All, It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? In Philipp's article. Note that test layers don't have to be classes. Classes with class methods just happen to be a (seductively) convenient implementation. For example, ZCMLLayer defined in zope.app.testing.functional is not a class, in the sense that Layer instances are not classes. A layer is simply an object that has __module__, __name__, and __bases__ attributes and that has setUp and tearDown methods. That's it. You can achieve that any way you want. I regret the use of the __bases__ attribute. It would have been better if I had left it up to layer implementations to call base layers, rather than having the test runner call them automatically. It was a bad automation tradeoff. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Jim Fulton wrote:
Am I right in assuming that there aren't any good narrative docs for
test layers?
This is obviously in the eye of the beholder. I'm sure the people
who created narratives tried to do a good job. Perhaps you can do better.
I may be missing some then... which narratives are you thinking of?
And yes, I'm hoping to do better unless I've just missed some existing
docs...
I've attached a test file which opened my eyes... how do I go about
weaving this into a doctest?
Now, related to this, say I have content objects X and Y, which are
expensive to set up. I have LayerX which sets up a sample content
object X, and LayerY which does the same for content object Y. This is
fine for tests which need one or other content type, but how do I
write tests which need both?
You create a layer that extends both.
How so?
Here's a sample of why I'm struggling:
class ZODB:
@classmethod
def setUp(cls):
... open zodb connection
... begin transaction
@classmethod
def tearDown(cls):
... abort transaction
... close connection
class LayerX(ZODB):
@classmethod
def setUp(cls):
cls.savepoint = transaction.savepoint()
... create X instance
@classmethod
def tearDown(cls):
cls.savepoint.rollback()
class LayerY(ZODB):
def setUp(cls):
cls.savepoint = transaction.savepoint()
... create Y instance
@classmethod
def tearDown(cls):
cls.savepoint.rollback()
class MyLayer(LayerX,LayerY): pass
class MyTests(TestCase):
layer = '.MyLayer'
def setUp(self):
self.savepoint = transaction.savepoint()
def tearDown(self):
self.savepoint.rollback()
def test_1(self):
pass
Basically, will the above work or will the savepoints become a horrible
jumbled mess and I end up with several ZODB connections as well?
cheers,
Chris
PS: can I use '.MyLayer' as a layer, or do I always need to put the full
dotted path in?
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
from unittest import TestSuite, makeSuite, TestCase
class MyLayer:
@classmethod
def setUp(self):
# do something here
print 'L1 setup'
print self
@classmethod
def tearDown(self):
# undo it here
print 'L1 teardown'
class MyExtendedLayer(MyLayer):
@classmethod
def setUp(self):
# do additional stuff here
# don't call super
print 'L2 setup'
@classmethod
def tearDown(self):
# undo it only the additional stuff here
# don't call super
print 'L2 teardown'
raise RuntimeError('fubar MyExtendedLayer.tearDown')
class T1(TestCase):
layer = 'Products.MyProduct.tests.test_layers.MyLayer'
def setUp(self):
print T1 setup
def tearDown(self):
print T1 teardown
def test_1(self):
print 'T1.1'
def test_2(self):
print 'T1.2'
def test_3(self):
print 'T1.3'
raise RuntimeError('fubar T1.test_3')
class T2(TestCase):
layer = 'Products.MyProduct.tests.test_layers.MyExtendedLayer'
def setUp(self):
print T2 setup
def tearDown(self):
print T2 teardown
raise RuntimeError('fubar')
def test_1(self):
print 'T2.1'
def test_2(self):
print 'T2.2'
def test_3(self):
print 'T2.3'
raise RuntimeError('fubar T2.test_3')
class T3(TestCase):
def setUp(self):
print T3 setup
raise RuntimeError('fubar')
def tearDown(self):
print T3 teardown
def test_1(self):
print 'T3.1'
def test_suite():
suite = TestSuite()
suite.addTest(makeSuite(T1))
suite.addTest(makeSuite(T2))
suite.addTest(makeSuite(T3))
return suite
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Jim Fulton wrote: A layer is simply an object that has __module__, __name__, and __bases__ attributes and that has setUp and tearDown methods. That's it. You can achieve that any way you want. I regret the use of the __bases__ attribute. It would have been better if I had left it up to layer implementations to call base layers, rather than having the test runner call them automatically. It was a bad automation tradeoff. Is it too late to add an explicit Layer class to zope.testing that deals with this properly rather than confusing n00bs like me? (even if it does involve some BBB if/then/else'ing in testrunner.py...) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] another layers quicky?
Hi (yet) again ;-) class MyLayer: @classmethod def setUp(self): self.app = Testing.ZopeTestCase.Zope2.app() @classmethod def tearDown(self): Testing.ZopeTestCase.close() class MyTests(TestCase): def setUp(self): self.savepoint = transaction.savepoint() self.app = makerequest(?.app) def tearDown(self): self.savepoint.rollback() ... What do I put in place of the ? to get hold of the layer's app? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Jim Fulton wrote: Chris Withers wrote: Hi All, It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? In Philipp's article. I may have spoken too soon. It looks like there is code to handle the object-as-base case in the test runner, at least on the trunk. Perhaps the version used by zope3 doesn't handle this case, or perhaps there's a bug that needs to be pursued. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Chris Withers wrote: Jim Fulton wrote: Am I right in assuming that there aren't any good narrative docs for test layers? This is obviously in the eye of the beholder. I'm sure the people who created narratives tried to do a good job. Perhaps you can do better. I may be missing some then... which narratives are you thinking of? You cited 3 in your note. ... Now, related to this, say I have content objects X and Y, which are expensive to set up. I have LayerX which sets up a sample content object X, and LayerY which does the same for content object Y. This is fine for tests which need one or other content type, but how do I write tests which need both? You create a layer that extends both. How so? You create a layer whose __bases__ include LayerX and LayerY. If you're layers happen to be implemented as classic classes, you then could use subclassing. Here's a sample of why I'm struggling: class ZODB: @classmethod def setUp(cls): ... open zodb connection ... begin transaction @classmethod def tearDown(cls): ... abort transaction ... close connection class LayerX(ZODB): @classmethod def setUp(cls): cls.savepoint = transaction.savepoint() ... create X instance @classmethod def tearDown(cls): cls.savepoint.rollback() class LayerY(ZODB): def setUp(cls): cls.savepoint = transaction.savepoint() ... create Y instance @classmethod def tearDown(cls): cls.savepoint.rollback() class MyLayer(LayerX,LayerY): pass class MyTests(TestCase): layer = '.MyLayer' def setUp(self): self.savepoint = transaction.savepoint() def tearDown(self): self.savepoint.rollback() def test_1(self): pass Basically, will the above work or will the savepoints become a horrible jumbled mess and I end up with several ZODB connections as well? That's a good question. Looking at the code on the zope.testing trunk, it looks like this should work. PS: can I use '.MyLayer' as a layer, or do I always need to put the full dotted path in? You have to use a full dotted path. You can also use the Layer object itself. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Jim Fulton wrote: I may have spoken too soon. It looks like there is code to handle the object-as-base case in the test runner, at least on the trunk. Perhaps the version used by zope3 doesn't handle this case, or perhaps there's a bug that needs to be pursued. That'd explain it, I'm using 2.9.4 ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Test Layers
Jim Fulton wrote: I may be missing some then... which narratives are you thinking of? You cited 3 in your note. I'd like there to be a good narrative that actually ships in zope.testing, I'm willing to do the work to make that happen provided I can get some help on writing the doctest of zope.testing that's required... You create a layer whose __bases__ include LayerX and LayerY. If you're layers happen to be implemented as classic classes, you then could use subclassing. What happens with new style classes? Basically, will the above work or will the savepoints become a horrible jumbled mess and I end up with several ZODB connections as well? That's a good question. I was afraid you'd say that ;-) Looking at the code on the zope.testing trunk, it looks like this should work. I'll give it a try with Zope 2.9 then... if you hear my screams of pain from across the atlantic, you'll know something hasn't worked right... PS: can I use '.MyLayer' as a layer, or do I always need to put the full dotted path in? You have to use a full dotted path. You can also use the Layer object itself. Ah, didn't know you could use the Layer object itself... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: layers can't be new style classes?
whit wrote: there is also a version of ztc by layers for 2.9(see zope2 branches) Which branch exactly? I'm using 2.9.4 and can't see any evidence of layers... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: layers can't be new style classes?
Chris Withers wrote: Jim Fulton wrote: I may have spoken too soon. It looks like there is code to handle the object-as-base case in the test runner, at least on the trunk. Perhaps the version used by zope3 doesn't handle this case, or perhaps there's a bug that needs to be pursued. That'd explain it, I'm using 2.9.4 ;-) Chris there is also a version of ztc by layers for 2.9(see zope2 branches) -w ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] testing and savepoints
Hi all, (sorry if some of this is Zope 2 - ish, the thread kinda started here and the underlying bits of this are certainly relevant to Zope 3) As you may have guessed by the flurry of mails today, I've been refactoring a 2000 test suite to use layers. I was hoping to use savepoints to speed things up... Each layer drops a savepoint in setUp and then rolls it back it in tearDown. Likewise, the TestCase's setUp would drop a savepoint and the tearDown would roll back to it. Sounds great, no? Well, no, actually: 1. Usual problems of some datamanagers not supporting savepoints. MaildropHost and some of the project's own products datamanagers do. mxODBC does not :-/ 2. dropping savepoints is slow. Figuring this might be due to saving data from the layer each time transaction.savepoint() is called, I thought of getting round this by dropping a savepoint at the end of the layer's setUp method. This did make thing a litte better, but: 3. savepoints are really slow :-( What's the usecase for savepoints? I would have thought this kind of thing would be ideal, but they seem really slow... For example, the above test suite takes about 300s to run prior to introducing layers. Using savepoints in place of transaction.commit()'s meant it took over 400s! :-( So I'm left what the actual use for savepoints is and if they could be made any faster? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: another layers quicky?
Chris Withers wrote: Hi (yet) again ;-) class MyLayer: @classmethod def setUp(self): self.app = Testing.ZopeTestCase.Zope2.app() @classmethod def tearDown(self): Testing.ZopeTestCase.close() Shrug! That will modify the class! self is the class here (it's convention to call it cls when using @classmethod). class MyTests(TestCase): def setUp(self): self.savepoint = transaction.savepoint() self.app = makerequest(?.app) def tearDown(self): self.savepoint.rollback() ... What do I put in place of the ? to get hold of the layer's app? self.layer.app ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: another layers quicky?
Philipp von Weitershausen wrote: What do I put in place of the ? to get hold of the layer's app? self.layer.app but self.layer is a string, no? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: another layers quicky?
Philipp von Weitershausen wrote: Chris Withers wrote: Philipp von Weitershausen wrote: What do I put in place of the ? to get hold of the layer's app? self.layer.app but self.layer is a string, no? Huh? No, it's the layer object (e.g. the class) even if you do: class MyTests(TestCase): layer = 'X.Y.Z' ? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: another layers quicky?
Chris Withers wrote: Philipp von Weitershausen wrote: Chris Withers wrote: Philipp von Weitershausen wrote: What do I put in place of the ? to get hold of the layer's app? self.layer.app but self.layer is a string, no? Huh? No, it's the layer object (e.g. the class) even if you do: class MyTests(TestCase): layer = 'X.Y.Z' ? No. Who said you should do that? Will a string even work? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: another layers quicky?
Philipp von Weitershausen wrote: ? No. Who said you should do that? http://zopewiki.org/TestLayersHowTo Will a string even work? Yes. Chris - anyway, right now I'm more annoyed that savepoints are sllooo and DemoStorage doesn't support undo... help with either would be much appreciated... -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: another layers quicky?
On Tue, Oct 17, 2006 at 05:40:51PM +0100, Chris Withers wrote: Philipp von Weitershausen wrote: ? No. Who said you should do that? http://zopewiki.org/TestLayersHowTo ... and more authoritatively, a number of tests in zope/testing/testrunner-ex use strings. Prior to the introduction of testrunner-layers-api.txt, there wasn't much else to go on. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
On Tue, Oct 17, 2006 at 11:30:46AM +0100, Chris Withers wrote: Hi All, It would appear that Philipp's article is somewhat misleading in that layers can't be new style classes... class MyLayer(object): def setUp(self): pass def tearDown(self): pass ..results in the following when used as a layer: AttributeError: type object 'object' has no attribute 'setUp' Is this a bug in Philipp's article or in the testrunner? I noticed the same thing when I wrote my zopewiki page (http://zopewiki.org/TestLayersHowTo) but it looks like new-style classes should work now, judging by this svn log message: r68925 | Zen | 2006-06-30 07:49:37 -0400 (Fri, 30 Jun 2006) | 3 lines Fix ordering of testSetUp and testTearDown calls, and allow new style classes to be used as Layers by explicitly ignoring the object baseclass. Also, at the time I wrote that page (in July), I wasn't aware of zope/testing/testrunner-layers-api.txt which would've saved me some trial and error. That may be the narrative you're looking for? I'll update the zopewiki page with a reference to that doc. Looks like that file is shipped with Zope 2.10.0 and 2.9.5, but it wasn't in 2.9.4. I haven't been living on the bleeding edge lately so I didn't see it. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: testing and savepoints
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Withers wrote: Hi all, (sorry if some of this is Zope 2 - ish, the thread kinda started here and the underlying bits of this are certainly relevant to Zope 3) As you may have guessed by the flurry of mails today, I've been refactoring a 2000 test suite to use layers. I was hoping to use savepoints to speed things up... Each layer drops a savepoint in setUp and then rolls it back it in tearDown. Likewise, the TestCase's setUp would drop a savepoint and the tearDown would roll back to it. Sounds great, no? Well, no, actually: 1. Usual problems of some datamanagers not supporting savepoints. MaildropHost and some of the project's own products datamanagers do. mxODBC does not :-/ 2. dropping savepoints is slow. Figuring this might be due to saving data from the layer each time transaction.savepoint() is called, I thought of getting round this by dropping a savepoint at the end of the layer's setUp method. This did make thing a litte better, but: 3. savepoints are really slow :-( What's the usecase for savepoints? I would have thought this kind of thing would be ideal, but they seem really slow... For example, the above test suite takes about 300s to run prior to introducing layers. Using savepoints in place of transaction.commit()'s meant it took over 400s! :-( So I'm left what the actual use for savepoints is and if they could be made any faster? Dunno, but this question belongs on zodb-dev. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNRbm+gerLs4ltQ4RArYgAJ9NYbG6fk3dL2D554JYkr1WxX17IgCg1UKU 2r+I33mqdDRHaUWTPKyvXfc= =h1Tg -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] testing and savepoints
On Oct 17, 2006, at 12:01 PM, Chris Withers wrote: So I'm left what the actual use for savepoints is 1) you want to reduce your memory usage within a transaction 2) a) sometimes you want to roll back to a certain point in a transaction. b) sometimes you do this in a context of an assembled application, in which other components may want to do the same thing, conceivably within the execution context of one another. transaction.commit(1) accomplished 1 and 2a. savepoint is a common concept (http://en.wikipedia.org/wiki/Savepoint) that also accomplishes 2b. and if they could be made any faster? Don't know. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] testing and savepoints
Jim Fulton wrote: Each layer drops a savepoint in setUp and then rolls it back it in tearDown. Likewise, the TestCase's setUp would drop a savepoint and the tearDown would roll back to it. This is a risky approach. If you have any software that does actual commits, you'll be hosed. Not sure what you mean by that... The reason I want to use savepoints is for ease of tearDown... I suggest using demo storages instead. Demo storages will also be faster. ...I'm already using DemoStorage. Well, they are going to make any approach like this difficult. That's why I avoid them. Still leaves me wondering why they were implemented :-S They seem ideal for this kind of thing... 3. savepoints are really slow :-( ditto. I'm guessing the savepoint speed is going to be dictated by the underlying storage? Which storage is your comment based on? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] layers can't be new style classes?
Paul Winkler wrote: Is this a bug in Philipp's article or in the testrunner? I noticed the same thing when I wrote my zopewiki page (http://zopewiki.org/TestLayersHowTo) but it looks like new-style classes should work now, judging by this svn log message: r68925 | Zen | 2006-06-30 07:49:37 -0400 (Fri, 30 Jun 2006) | 3 lines Fix ordering of testSetUp and testTearDown calls, and allow new style classes to be used as Layers by explicitly ignoring the object baseclass. Yes indeed... Also, at the time I wrote that page (in July), I wasn't aware of zope/testing/testrunner-layers-api.txt which would've saved me some trial and error. That may be the narrative you're looking for? I'll update the zopewiki page with a reference to that doc. Looks like that file is shipped with Zope 2.10.0 and 2.9.5, but it wasn't in 2.9.4. I haven't been living on the bleeding edge lately so I didn't see it. Yup, the narrative I was missing is here: http://svn.zope.org/zope.testing/trunk/src/zope/testing/testrunner-layers-api.txt?rev=70271view=auto I guess it's time for me to move to a newer zope.testing ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] testing and savepoints
Chris Withers wrote: Jim Fulton wrote: Each layer drops a savepoint in setUp and then rolls it back it in tearDown. Likewise, the TestCase's setUp would drop a savepoint and the tearDown would roll back to it. This is a risky approach. If you have any software that does actual commits, you'll be hosed. Not sure what you mean by that... The reason I want to use savepoints is for ease of tearDown... Yes, but if anything dos an actual commit, your tear down won't be able to roll it back. I suggest using demo storages instead. Demo storages will also be faster. ...I'm already using DemoStorage. Cool. Then why are you trying to use a savepoint. You do realize that you can stack demo storages. Create a demo storage for the layer and test and toss the database when you're done. Look at the way zope.app.testing.functional works for an example. Well, they are going to make any approach like this difficult. That's why I avoid them. Still leaves me wondering why they were implemented :-S They seem ideal for this kind of thing... I really don't know why relational databases were implemented. I'm not really the one to ask. ;) 3. savepoints are really slow :-( ditto. I'm guessing the savepoint speed is going to be dictated by the underlying storage? I doubt it, Which storage is your comment based on? FileStorage, ClientStorage, DemoStorage. Savepoints write their data to temporary files. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] testing and savepoints
Jim Fulton wrote: You do realize that you can stack demo storages. Would I be torturing myself like this if I did? ;-) Create a demo storage for the layer and test and toss the database when you're done. Look at the way zope.app.testing.functional works for an example. Yay! Thankyou :-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] testing and savepoints
On Tuesday 17 October 2006 14:47, Jim Fulton wrote: You do realize that you can stack demo storages. Create a demo storage for the layer and test and toss the database when you're done. Look at the way zope.app.testing.functional works for an example. Yep, we utilize that functional setup too, but provide our own base_storage. This way we can have a generated testing database that can be deleted and is automatically generated when missing. Each new functional test using this layer gets a fresh database of this kind. Here is our layer setup: class RecruiterSiteLayer(object): A special layer that sets up a well-populated recruiter site. __name__ = RecruiterSiteLayer __bases__ = (functional.Functional,) seed = 'Recruiter' def setUp(self): fsetup = functional.FunctionalTestSetup() self.original = fsetup.base_storage filename = os.path.join(os.path.dirname(__file__), 'testing.fs') if not os.path.exists(filename): oldPolicy = management.setSecurityPolicy(PermissiveSecurityPolicy) management.newInteraction(SetupConfigurationParticipation()) # Generate a new database from scratch and the fill it with the # sample data db = database(filename) connection = db.open() root = connection.root() app = root[ZopePublication.root_name] generator.generate(app, self.seed) transaction.commit() connection.close() db.close() management.endInteraction() management.setSecurityPolicy(oldPolicy) fsetup.base_storage = FileStorage(filename) fsetup.setUp() def tearDown(self): fsetup = functional.FunctionalTestSetup() fsetup.base_storage = self.original fsetup.tearDown() RecruiterSiteLayer = RecruiterSiteLayer() The generator is a z3c.sampledata generator. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
