[Zope3-dev] testing and savepoints

[Jim Fulton]

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:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org