FunctionalTestCase commits transactions
I'm trying to get zope.testbrowser to work in Zope 2.10. After a lot of guesswork (easy_install zope.testbrowser broke my environment, Zope 2.11 isn't setting up session container, used various blogs tips to get adapters right) I got it running and I can now do stuff like browser.open(self.folder.myapp.absolute_url()) in python unit test. However, I have a problem. The app uses ZSQL Methods and when the test finishes the transaction is not rolled back and I'm not interested in manually resetting the test database. Is this so deliberately? Do I really have to manually reset the database? I noticed that FunctionTestCase (lib/python/Testing/ZopeTestCase/ZopeTestCase.py:116) inherits from functional.Functional which inherits from sandbox.SandBoxed which, although I don't understand it, seems to do things differently to the non-functional approach which inherits from base.TestCase. Although I'm not using it, function.Functional adds the nifty function publish() which I'm not using but it's not a transaction.commit() in it. Why?? And what does that decorator actually do? Peter class Functional(sandbox.Sandboxed): ... __implements__ = (interfaces.IFunctional,) @savestate def publish(self, path, basic=None, env=None, extra=None, request_method='GET', stdin=None, handle_errors=True): '''Publishes the object at 'path' returning a response object.''' ... # Commit the sandbox for good measure transaction.commit() ... -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
"Peter Bengtsson" <peter@fry-it.com> writes:
I'm trying to get zope.testbrowser to work in Zope 2.10. After a lot of guesswork (easy_install zope.testbrowser broke my environment, Zope 2.11 isn't setting up session container, used various blogs tips to get adapters right) I got it running and I can now do stuff like browser.open(self.folder.myapp.absolute_url()) in python unit test. However, I have a problem. The app uses ZSQL Methods and when the test finishes the transaction is not rolled back and I'm not interested in manually resetting the test database. Is this so deliberately? Do I really have to manually reset the database?
I noticed that FunctionTestCase (lib/python/Testing/ZopeTestCase/ZopeTestCase.py:116) inherits from functional.Functional which inherits from sandbox.SandBoxed which, although I don't understand it, seems to do things differently to the non-functional approach which inherits from base.TestCase.
Although I'm not using it, function.Functional adds the nifty function publish() which I'm not using but it's not a transaction.commit() in it. Why?? And what does that decorator actually do?
If memory serves, a *functional* test fixture calls the Zope publisher when a testbrowser request is made. The publisher opens a new transaction, as it should. So if there are uncommitted changes in the transaction used by the test before submitting the testbrowser request, then those changes won't be reflected in the new transaction opened when the publisher handles the request. I'm guessing that since this is a fairly common situation it was decided that the test case should commit before submitting the request to the Zope publisher. I think it's proper that a *functional* test case opens a new transaction when responding to requests since that's how the application behaves. I also think that it's proper for a widely shared test fixture such as this to gracefully handle the common case where a test writer needs changes made in the test to show up when handling the request as it does now. I *also* agree that your case is the purer one and that should be supported. So I guess I'd advocate for making the commit in the Functional.publish() method configurable. At any rate, to solve your immediate problem, I would just write a new test case class that subclasses whatever test case class you were using, copy the publish method implementation from Functional and just remove the commit line. Then you can use your test case class in your tests and the commit won't be made. HTH, Ross
class Functional(sandbox.Sandboxed): ... __implements__ = (interfaces.IFunctional,)
@savestate def publish(self, path, basic=None, env=None, extra=None, request_method='GET', stdin=None, handle_errors=True): '''Publishes the object at 'path' returning a response object.''' ...
# Commit the sandbox for good measure transaction.commit() ...
Ross Patterson wrote at 2008-11-3 16:04 -0800:
... If memory serves, a *functional* test fixture calls the Zope publisher when a testbrowser request is made. The publisher opens a new transaction, as it should.
Really? When I wrote a functional test browser (years before "zope3"), I emulated the Zope publisher rather than calling it directly in order to have control how transactions are handled. Especially, I used subtransactions instead of top level transactions to avoid the bug reported by Peter. -- Dieter
"Dieter Maurer" <dieter@handshake.de> writes:
Ross Patterson wrote at 2008-11-3 16:04 -0800:
... If memory serves, a *functional* test fixture calls the Zope publisher when a testbrowser request is made. The publisher opens a new transaction, as it should.
Really?
When I wrote a functional test browser (years before "zope3"), I emulated the Zope publisher rather than calling it directly in order to have control how transactions are handled.
Especially, I used subtransactions instead of top level transactions to avoid the bug reported by Peter.
I'm not completely sure, but I'm *pretty* sure. I remember stepping through the code before and seeing a new transaction start. As for "as it should", it just seems reasonable to me that a functional test fixture would try to use the real application behavior as much as possible. Ross
2008/11/4 Dieter Maurer <dieter@handshake.de>:
Ross Patterson wrote at 2008-11-3 16:04 -0800:
... If memory serves, a *functional* test fixture calls the Zope publisher when a testbrowser request is made. The publisher opens a new transaction, as it should.
Really?
When I wrote a functional test browser (years before "zope3"), I emulated the Zope publisher rather than calling it directly in order to have control how transactions are handled.
Especially, I used subtransactions instead of top level transactions to avoid the bug reported by Peter.
Uh? "subtransactions"? So how would you recommend that I go abouts doing this? In fact I've already written a custom tearDown() for my class that cleans the test database (postgresql) which is quite neat because I can write tests in a completely different way as each test can build on each other (assuming order of methods is respected) similar to how doctests are done where you have blocks of shell code split between text. If this is the way it has to be to test with zope.testbrowser in zope 2 then I'll let it be so. -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
"Peter Bengtsson" <peter@fry-it.com> writes:
2008/11/4 Dieter Maurer <dieter@handshake.de>:
Ross Patterson wrote at 2008-11-3 16:04 -0800:
... If memory serves, a *functional* test fixture calls the Zope publisher when a testbrowser request is made. The publisher opens a new transaction, as it should.
Really?
When I wrote a functional test browser (years before "zope3"), I emulated the Zope publisher rather than calling it directly in order to have control how transactions are handled.
Especially, I used subtransactions instead of top level transactions to avoid the bug reported by Peter.
Uh? "subtransactions"? So how would you recommend that I go abouts doing this? In fact I've already written a custom tearDown() for my class that cleans the test database (postgresql) which is quite neat because I can write tests in a completely different way as each test can build on each other (assuming order of methods is respected) similar to how doctests are done where you have blocks of shell code split between text.
If this is the way it has to be to test with zope.testbrowser in zope 2 then I'll let it be so.
I don't think what Dieter is talking about is a viable path for you. I think he's talking about something *else* that he did in the past. I think you should use your approach or the one I suggested. Ross
Peter Bengtsson wrote at 2008-11-5 15:14 +0000:
...
When I wrote a functional test browser (years before "zope3"), I emulated the Zope publisher rather than calling it directly in order to have control how transactions are handled.
Especially, I used subtransactions instead of top level transactions to avoid the bug reported by Peter.
Uh? "subtransactions"? So how would you recommend that I go abouts doing this?
"savepoint"s have replaced subtransactions. This means: When a request starts, a new savepoint is created. When the request would cause a transaction abort (in normal operation), the test request will roll back to the saved savepoint. Otherwise, the modifications are kept. When the complete test ends, the transaction is aborted, wiping out all modifications done be the test. Of course, this works only when all resouce managers in the transaction support savepoints (which probably means that all resource managers need to be ZODB connections). -- Dieter
2008/11/17 Dieter Maurer <dieter@handshake.de>:
Peter Bengtsson wrote at 2008-11-5 15:14 +0000:
...
When I wrote a functional test browser (years before "zope3"), I emulated the Zope publisher rather than calling it directly in order to have control how transactions are handled.
Especially, I used subtransactions instead of top level transactions to avoid the bug reported by Peter.
Uh? "subtransactions"? So how would you recommend that I go abouts doing this?
"savepoint"s have replaced subtransactions.
This means:
When a request starts, a new savepoint is created. When the request would cause a transaction abort (in normal operation), the test request will roll back to the saved savepoint. Otherwise, the modifications are kept.
When the complete test ends, the transaction is aborted, wiping out all modifications done be the test. Of course, this works only when all resouce managers in the transaction support savepoints (which probably means that all resource managers need to be ZODB connections).
That's fine. When I used SQL connections in ZopeTestCase they are aborted and after running all tests my tables are empty as expected. With FunctionalTestCase this is not the case. It seems to have to commit transactions (save savepoints). I solved my situation by writing a custom tearDown() method that manually resets the tables. Kind of like this: class TestFunctionalBase(ZopeTestCase.FunctionalTestCase): def tearDown(self): sql = 'TRUNCATE TABLE table1, table2, table3;' self.pypgsqlda.manage_test(sql) import transaction transaction.commit() super(TestFunctionalBase, self).tearDown()
-- Dieter _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com
participants (3)
-
Dieter Maurer -
Peter Bengtsson -
Ross Patterson