Switching zope.testbrowser to webtest instead of mechanize
Hello zope-dev, As you may already know, there is an effort to port zope packages to Python 3 going on. As part of this effort we want to port zope.testbrowser. Unfortunately, mechanize package, that zope.testbrowser depends on has no py3 support. There is an unfinished effort at [1], however, after closer examination of the codebase and state of the port, it seems more practical to switch internal implementation of zope.testbrowser to webtest. So far, it seems webtest has all the features needed to do the switch. I started a branch at github ([2]) to track work in progress. The goal is to make most (say 80%) of existing tests to work without modifications under new implementation. [1] http://web.cecs.pdx.edu/~adevore/mechanize/ [2] https://github.com/zopefoundation/zope.testbrowser/tree/webtest -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru
On Mon, Mar 04, 2013 at 08:40:23PM +0200, Andrey Lebedev wrote:
Hello zope-dev,
As you may already know, there is an effort to port zope packages to Python 3 going on. As part of this effort we want to port zope.testbrowser.
Great! I'm very interested in this, I've also got an app which I'll need to port to python3 at some time.
Unfortunately, mechanize package, that zope.testbrowser depends on has no py3 support. There is an unfinished effort at [1], however, after closer examination of the codebase and state of the port, it seems more practical to switch internal implementation of zope.testbrowser to webtest.
So far, it seems webtest has all the features needed to do the switch. I started a branch at github ([2]) to track work in progress. The goal is to make most (say 80%) of existing tests to work without modifications under new implementation.
Looking at the branch, it seems that this is basically going to be a re-write of the existing code. You're planning to keep the mechanize backend available? Might I suggest zope.testbrowser.webtest for the WebTest backed testbrowser rather than zope.testbrowser.browser2? Could you also keep the tests for the mechanize testbrowser intact? They could be skipped if mechanize is not importable and mechanize downgraded to an optional dependency.
[1] http://web.cecs.pdx.edu/~adevore/mechanize/ [2] https://github.com/zopefoundation/zope.testbrowser/tree/webtest
-- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland
On 03/05/2013 05:10 PM, Brian Sutherland wrote:
So far, it seems webtest has all the features needed to do the
switch. I started a branch at github ([2]) to track work in progress. The goal is to make most (say 80%) of existing tests to work without modifications under new implementation.
Looking at the branch, it seems that this is basically going to be a re-write of the existing code.
Yes, it is a re-write, but not re-write from scratch. I use existing code as much as possible.
You're planning to keep the mechanize backend available?
Initially we didn't plan to keep mechanize. I think it would add an unjustified burden of choice to users (which backend to pick, if they work the same way?) and mechanize backend will/may not work in python3 anyway. The question of how compatible the webtest-based implementation will be, is still an open one though. However, we have a big real-world project to test compatibility against.
Might I suggest zope.testbrowser.webtest for the WebTest backed testbrowser rather than zope.testbrowser.browser2?
I admit there is a bit of mess right now in the branch as I need to preserve existing code to copy when applicable. My plan is to rename z.t.browser2 to z.t.browser eventually, so it is not a final name.
Could you also keep the tests for the mechanize testbrowser intact? They could be skipped if mechanize is not importable and mechanize downgraded to an optional dependency.
Again, if the compatibility of new implementation is proven to be "good enough", I see no reason to keep mechanize around. I might miss some important reasons, though. -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru
On Tue, Mar 05, 2013 at 05:56:54PM +0200, Andrey Lebedev wrote:
On 03/05/2013 05:10 PM, Brian Sutherland wrote:
So far, it seems webtest has all the features needed to do the
switch. I started a branch at github ([2]) to track work in progress. The goal is to make most (say 80%) of existing tests to work without modifications under new implementation.
Looking at the branch, it seems that this is basically going to be a re-write of the existing code.
Yes, it is a re-write, but not re-write from scratch. I use existing code as much as possible.
You're planning to keep the mechanize backend available?
Initially we didn't plan to keep mechanize. I think it would add an unjustified burden of choice to users (which backend to pick, if they work the same way?) and mechanize backend will/may not work in python3 anyway.
The question of how compatible the webtest-based implementation will be, is still an open one though. However, we have a big real-world project to test compatibility against.
You're right, the big question is how compatible the WebTest version will be. I don't think anyone will object to a drop-in replacement. Having to modify 20% of existing tests sounds like a lot. I guess we'll have to see how compatible the new browser will be. I'm willing to pitch in by testing it against my own application, please let me know when/if you want me to do that.
Might I suggest zope.testbrowser.webtest for the WebTest backed testbrowser rather than zope.testbrowser.browser2?
I admit there is a bit of mess right now in the branch as I need to preserve existing code to copy when applicable. My plan is to rename z.t.browser2 to z.t.browser eventually, so it is not a final name.
Ok!
Could you also keep the tests for the mechanize testbrowser intact? They could be skipped if mechanize is not importable and mechanize downgraded to an optional dependency.
Again, if the compatibility of new implementation is proven to be "good enough", I see no reason to keep mechanize around. I might miss some important reasons, though.
One thing which I'm not sure you can do with a webtest backend is using it as a real browser. i.e. you'll probably not get over_the_wire.txt to pass. However, I don't know of anyone who actually uses that functionality. Hmm, though I guess you can have a WSGI application that fires off real HTTP requests... -- Brian Sutherland
On 03/05/2013 06:45 PM, Brian Sutherland wrote:
One thing which I'm not sure you can do with a webtest backend is using it as a real browser. i.e. you'll probably not get over_the_wire.txt to pass. However, I don't know of anyone who actually uses that functionality.
Hm, webtest claims it can do this [1], but I haven't tested it myself yet. [1] http://webtest.pythonpaste.org/en/latest/testapp.html#testing-a-non-wsgi-app... -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru
On Tue, Mar 05, 2013 at 06:49:35PM +0200, Andrey Lebedev wrote:
On 03/05/2013 06:45 PM, Brian Sutherland wrote:
One thing which I'm not sure you can do with a webtest backend is using it as a real browser. i.e. you'll probably not get over_the_wire.txt to pass. However, I don't know of anyone who actually uses that functionality.
Hm, webtest claims it can do this [1], but I haven't tested it myself yet.
[1] http://webtest.pythonpaste.org/en/latest/testapp.html#testing-a-non-wsgi-app...
Nice! -- Brian Sutherland
On Monday, March 04, 2013 08:40:23 PM Andrey Lebedev wrote:
Unfortunately, mechanize package, that zope.testbrowser depends on has no py3 support. There is an unfinished effort at [1], however, after closer examination of the codebase and state of the port, it seems more practical to switch internal implementation of zope.testbrowser to webtest.
So far, it seems webtest has all the features needed to do the switch. I started a branch at github ([2]) to track work in progress. The goal is to make most (say 80%) of existing tests to work without modifications under new implementation.
An update here: The large zope.testbrowser README.txt file is now passing with WebTest in Python 2.7. There are a few more failures to fix, but Andrey is confident he can get those resolved quickly. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On 03/04/2013 08:40 PM, Andrey Lebedev wrote:
As you may already know, there is an effort to port zope packages to Python 3 going on. As part of this effort we want to port zope.testbrowser.
Status update: test suite passes on webtest backend under python-2.6, 2.7 and 3.3. Further things to do: make some performance improvements, try some real-world tests and release a alpha version. -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru
On Tue, Mar 19, 2013 at 04:40:02PM +0200, Andrey Lebedev wrote:
On 03/04/2013 08:40 PM, Andrey Lebedev wrote:
As you may already know, there is an effort to port zope packages to Python 3 going on. As part of this effort we want to port zope.testbrowser.
Status update: test suite passes on webtest backend under python-2.6, 2.7 and 3.3.
Further things to do: make some performance improvements, try some real-world tests and release a alpha version.
I tried it against my app with good results so far :) I did notice two regression and pushed failing tests to you py3 branch. It seemed the easiest/fastest way forward, if you'd rather I made a separate branch for these, let me know.
-- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
-- Brian Sutherland
On 03/19/2013 07:36 PM, Brian Sutherland wrote:
Further things to do: make some performance improvements, try some
real-world tests and release a alpha version. I tried it against my app with good results so far:)
I did notice two regression and pushed failing tests to you py3 branch. It seemed the easiest/fastest way forward, if you'd rather I made a separate branch for these, let me know.
Thanks. I'll try to look into these regressions tomorrow. Feel free to add tests to py3 branch. This way they won't get unnoticed. -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru
On Tue, Mar 19, 2013 at 04:40:02PM +0200, Andrey Lebedev wrote:
On 03/04/2013 08:40 PM, Andrey Lebedev wrote:
As you may already know, there is an effort to port zope packages to Python 3 going on. As part of this effort we want to port zope.testbrowser.
Status update: test suite passes on webtest backend under python-2.6, 2.7 and 3.3.
Further things to do: make some performance improvements, try some real-world tests and release a alpha version.
This is looking very very good, in my app very few tests are still failing. I poked around at one and found that the way non-ascii in forms is handled has changed under python 2, here's a test that shows the problem: https://github.com/zopefoundation/zope.testbrowser/commit/e0e965086c7fded415... I'm not sure what the intention of the python 3 port is wrt unicode. Have you had any thoughts on the matter? -- Brian Sutherland
On 04/12/2013 02:59 PM, Brian Sutherland wrote:
This is looking very very good, in my app very few tests are still failing.
Great! Now, as all our webtest fixes are released upstream, I plan to make an alpha release of what we've done so far. If you have any outstanding issues with new testbrowser, please report.
I poked around at one and found that the way non-ascii in forms is handled has changed under python 2, here's a test that shows the problem:
https://github.com/zopefoundation/zope.testbrowser/commit/e0e965086c7fded415...
Thanks, I've fixed the testbrowser according to your testcase.
I'm not sure what the intention of the python 3 port is wrt unicode. Have you had any thoughts on the matter?
The idea is to make testbrowser to return/accept native strings instead of bytes/unicode for both py2 and py3. Under py2, controls will return str objects (for backwards compatibility), and under py3 that would be unicode strings (for usage convenience). -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru
On Sat, Apr 13, 2013 at 12:54:22AM +0300, Andrey Lebedev wrote:
On 04/12/2013 02:59 PM, Brian Sutherland wrote:
This is looking very very good, in my app very few tests are still failing.
Great! Now, as all our webtest fixes are released upstream, I plan to make an alpha release of what we've done so far. If you have any outstanding issues with new testbrowser, please report.
Just committed the last two. Sorry for the drip feed, but it takes a while to make simple test cases from the failures I see in my app. +1 to an alpha release soon.
I poked around at one and found that the way non-ascii in forms is handled has changed under python 2, here's a test that shows the problem:
https://github.com/zopefoundation/zope.testbrowser/commit/e0e965086c7fded415...
Thanks, I've fixed the testbrowser according to your testcase.
perfect
I'm not sure what the intention of the python 3 port is wrt unicode. Have you had any thoughts on the matter?
The idea is to make testbrowser to return/accept native strings instead of bytes/unicode for both py2 and py3. Under py2, controls will return str objects (for backwards compatibility), and under py3 that would be unicode strings (for usage convenience).
I guessed correctly then :) -- Brian Sutherland
On 04/15/2013 01:42 PM, Brian Sutherland wrote:
Great! Now, as all our webtest fixes are released upstream, I plan to make an alpha release of what we've done so far. If you have any outstanding issues with new testbrowser, please report.
Just committed the last two. Sorry for the drip feed, but it takes a while to make simple test cases from the failures I see in my app.
Just fixed those. Thanks for testing and, especially, for testcases, Brian. I understand they must be much harder for you to write, than for me to fix them. -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://lebedev.lt/ Jabber ID: kedder@jabber.ru
On Wed, Apr 17, 2013 at 11:15:35PM +0300, Andrey Lebedev wrote:
On 04/15/2013 01:42 PM, Brian Sutherland wrote:
Great! Now, as all our webtest fixes are released upstream, I plan to make an alpha release of what we've done so far. If you have any outstanding issues with new testbrowser, please report.
Just committed the last two. Sorry for the drip feed, but it takes a while to make simple test cases from the failures I see in my app.
Just fixed those.
Great, I've just confirmed that I have no more test failures in my app caused by bugs in the new testbrowser. I've found two that are bugs in the old testbrowser though, where tests passed by mistake ;) -- Brian Sutherland
participants (3)
-
Andrey Lebedev -
Brian Sutherland -
Stephan Richter