Re: [Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
Stephan Richter wrote: As I said, I have not thought too hard about a specific API recommendation yet, but I believe I have enough experience now to think about it now. I like the general "feel" of it. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
On Saturday 24 June 2006 22:35, Benji York wrote:
> > I would also like to think much harder about a good set of HTML
> > analyzing tools; this function was supposed to be a start in the
> > right direction, but I never got around thinking harder about it.
>
> Which function is "this function"?
analyze.queryHTML() in the referenced SchoolTool code. I think some
higher-level functions would be desirable, like: "Get text of the specified
tag." or "Ensure that no links are broken." The latter is particularly useful
when checking for security. But all of this should be an additional API on
top of testbrowser of course. I think the following would be cool:
>>> Analyzer(browser).checkForBrokenLinks()
>>> Analyzer(browser).getText('//h1')
'Title of Page'
Often I also have results of the sort:
Well Done!
by SchoolTool Manager
on ...
A job well done.
Then I would like something like this to work:
>>> print Analyzer(browser).getTextOnly('//[EMAIL PROTECTED]"commendation"]')
Well Done!
by SchoolTool Manager on ...
A job well done.
All I want to ensure is that the right text is shown together. I do not care
whether this commendation is the first, n-th or last commendation in the
HTML.
In other scenarios I specifically want to test for order only:
>>> Analyzer(browser).getTextInOrder(
... '//[EMAIL PROTECTED]"commendation"]/h3')
['Good job!', 'Well Done', 'Fantastic']
As I said, I have not thought too hard about a specific API recommendation
yet, but I believe I have enough experience now to think about it now.
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
Re: [Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
Stephan Richter wrote: Sorry, I did not parse (or better, my lexicon did not recognize the patterm ;-) the last part of the sentence. You answered the question anyway. :) I often like the XPATH selection, but the simplicity of the current control selectors is very nice too and I would not want to miss it. That's what I wanted to know. I would be happy to replace the regex support with XPATH though. Me too, especially since the regex support is not documented and as such may be retracted in the future. :) I would also like to think much harder about a good set of HTML analyzing tools; this function was supposed to be a start in the right direction, but I never got around thinking harder about it. Which function is "this function"? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
On Saturday 24 June 2006 21:43, Benji York wrote: > Stephan Richter wrote: > > On Saturday 24 June 2006 19:49, Martin Aspeli wrote: > >> In this case, having the ability to select nodes by XPATH would be > >>incredibly useful > > > > Yes, I have done that in SchoolTool already. > > I'm curious if the other ways of selecting things were no longer > necessary, or if each still had a place. Sorry, I did not parse (or better, my lexicon did not recognize the patterm ;-) the last part of the sentence. I often like the XPATH selection, but the simplicity of the current control selectors is very nice too and I would not want to miss it. I would be happy to replace the regex support with XPATH though. I would also like to think much harder about a good set of HTML analyzing tools; this function was supposed to be a start in the right direction, but I never got around thinking harder about it. 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
Re: [Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
Stephan Richter wrote: On Saturday 24 June 2006 19:49, Martin Aspeli wrote: In this case, having the ability to select nodes by XPATH would be incredibly useful Yes, I have done that in SchoolTool already. I'm curious if the other ways of selecting things were no longer necessary, or if each still had a place. -- Benji York Senior Software Engineer Zope Corporation ___ 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: XPATH in zope.testbrowser, assertions in zope.testrecorder
Martin Aspeli wrote: Benji York wrote: With ElementTree going into Python 2.5, I suspect testbrowser will grow XPath support. > Great! (of course, if we could have it sooner) :p I'm hesitant to add another dependency to Zope 3, especially something as grotesque as libxml2. :) ET seems like a good alternative. We can add ET to Z3 (either the pure-Python or C version) and after Python 2.5 is the oldest supported version, remove it. I looked at zope.testrecorder and thought, hey, that looks simple! Then I saw the .js file... ;-) Yeah, the implementation is necessarily somewhat hairy. Realistically, I don't think I'm likely to have time Same here. Yeah, that was my thinking. Actually, I'd prefer if it just rendered it as a '%s/foo' % base_url, where base_url was a variable. That way the test case could do e.g. base_url = self.portal.absolute_url() and we wouldn't have to hardcode anything. For Zope 3 functional tests where the netloc is ignored that would unnecessarily clutter the resulting tests. If it's going to be a fixed value, I prefer the current behavior. Configurablity sounds good here. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
On Saturday 24 June 2006 19:49, Martin Aspeli wrote: > In this case, having the ability to select nodes by XPATH would be > incredibly useful - both for getControl()/getLink(), and for doing > assertions (fail if/unless this node exists). I imagine an existing > library would be available to make this reasonably easy to implement? Yes, I have done that in SchoolTool already. It uses straight libxml2, so no fancy lxml or ElementTree, but it works well. We use it far too little. The code is here: http://source.schooltool.org/viewcvs/trunk/schooltool/src/schooltool/testing/analyze.py?rev=5667&view=auto And here it is used: http://source.schooltool.org/viewcvs/trunk/schooltool/src/schooltool/commendation/Viewing.txt?rev=6137&view=auto 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
[Zope3-dev] Re: XPATH in zope.testbrowser, assertions in zope.testrecorder
Benji York wrote: Martin Aspeli wrote: o In zope.testbrowser, [snip] having the ability to select nodes > by XPATH would be incredibly useful Yep, I and others have thought the same thing. Cool. Philipp mentioned that lxml may have a nice API for this, too. I imagine an existing library would be available to make this reasonably easy to implement? With ElementTree going into Python 2.5, I suspect testbrowser will grow XPath support. Great! (of course, if we could have it sooner) :p o In zope.testrecorder, the ability to add comments that become DocTest comments is a stroke of genius. What I'd love to see, though, is the ability to add assertions for text. We've considered that too. Patches welcome. :) I looked at zope.testrecorder and thought, hey, that looks simple! Then I saw the .js file... ;-) Realistically, I don't think I'm likely to have time to figure out how this works and make changes in the near future (too many other projects). If I can find the time (or find someone else who has the necessary skill) I would of course love to help out. o Finally, zope.testrecorder always records full URLs, e.g. http://localhost:8080/test/foo. It would be nice if it could render those in the doctest at least with some variable substitution, e.g.: Good idea. The post-record screen (where you choose either Selenium or testbrowser output) would be a good place for that. You could choose any substitution you wanted for the host and port portion of the URIs, defaulting to whatever the actual value was. Yeah, that was my thinking. Actually, I'd prefer if it just rendered it as a '%s/foo' % base_url, where base_url was a variable. That way the test case could do e.g. base_url = self.portal.absolute_url() and we wouldn't have to hardcode anything. We would have to handle the case when more than one base was recorded during the session. True. It wouldn't be too hard to go through the urls in use and present a table of text boxes where you could map each to a variable (or leave as default), I guess. Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
Martin Aspeli wrote: o In zope.testbrowser, [snip] having the ability to select nodes > by XPATH would be incredibly useful Yep, I and others have thought the same thing. I imagine an existing library would be available to make this reasonably easy to implement? With ElementTree going into Python 2.5, I suspect testbrowser will grow XPath support. o In zope.testrecorder, the ability to add comments that become DocTest comments is a stroke of genius. What I'd love to see, though, is the ability to add assertions for text. We've considered that too. Patches welcome. :) o Finally, zope.testrecorder always records full URLs, e.g. http://localhost:8080/test/foo. It would be nice if it could render those in the doctest at least with some variable substitution, e.g.: Good idea. The post-record screen (where you choose either Selenium or testbrowser output) would be a good place for that. You could choose any substitution you wanted for the host and port portion of the URIs, defaulting to whatever the actual value was. We would have to handle the case when more than one base was recorded during the session. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] XPATH in zope.testbrowser, assertions in zope.testrecorder
Hi guys,
I just started using zope.testbrowser and zope.testrecorder for doing
integration tests. The case study is Ploneboard, the long-overdue
message board for Plone, which has a workflow maze to compete with the
best of them. Permissions control actions like reply, delete, edit and
approve/moderate, which vary according to the different types of forum
(e.g. moderated vs. non-moderated), and forms can get pretty complex.
zope.testbrowser gives us a way to sanity-check all that - I love it :)
There are three features I've found myself missing, though.
o In zope.testbrowser, I sometimes need to be quite specific; for
example, let's say I need to test that user A can see an 'edit' button
on his own post, but not on the post by user B, both of which appear on
the same page.
In this case, having the ability to select nodes by XPATH would be
incredibly useful - both for getControl()/getLink(), and for doing
assertions (fail if/unless this node exists). I imagine an existing
library would be available to make this reasonably easy to implement?
o In zope.testrecorder, the ability to add comments that become
DocTest comments is a stroke of genius. What I'd love to see, though, is
the ability to add assertions for text. Basically, if I could mark some
text in the browser and have that become a statement like
>>> browser.contents
'...some text in the browser...'
... then that would go a long way towards making the post-processing of
the rendered DocTest a very minimal exercise.
o Finally, zope.testrecorder always records full URLs, e.g.
http://localhost:8080/test/foo. It would be nice if it could render
those in the doctest at least with some variable substitution, e.g.:
>>> baseUrl = 'http://localhost:8080/test'
...
>>> browser.open('%s/foo' % baseUrl)
That way, I could make sure that in integration tests, the baseUrl was
always valid and consistent without needing to do a lot of
search-and-replace.
Cheers,
Martin
___
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: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Philipp von Weitershausen wrote: Dmitry Vasiliev wrote: Log message for revision 68818: Fixed issue 525: DateWidget ru-format - type="text" value="2002-12-02 12:30:00" /> + type="text" value="2002 12 2 12:30:00 " /> Note that a EditForm can't make use of a get_rendered method. The get_rendered method does only set initial values. Why does the display of the default DateTime widget change? ...and in such a strange way? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: eggs in a Zope 3.3 instance
Jim Fulton wrote: >> Jim Fulton wrote: Concretely, what do you think about making lib/python in a Zope 3.3 instance a site for now (calling site.addsitedir())? >>> >>> I think it's a bad idea, mainly because it's too late to make such a >>> change for 3.3. I tell you what I will do though, I'll promise, by >>> the end of EP, to have a buildout that lets you define Zope 3.3 >>> instances with the eggs of your choice. >> >> That sounds very interesting. However, zc.buildout is clearly aimed at >> large deployment. A *simple* way of deploying eggs in instances would >> still be needed (*I* need it, in fact); > > I'm confident that zc.buildout will serve simple cases well. The > zc.buildout project itself *is* an example of a simple buildout and I > think it is serving itself rather well. :) Good. I shall invest some time in playing with it then. >> if not in Zope 3.3, then at >> least later. Currently you only have to drop package directories into >> INSTANCE/lib/python, something similar with eggs should also be possible. >> I frequently get lost between sys.path, sys.prefix, .pth files and the >> site.py module. The fact that a one line fix gets what we want seems >> simple enough to me. As said, I'm not the expert here, though :) > > I doubt we are going to make our release target as it is. I don't think > any feature change, especially one with such far reaching ramifications > is justified. > > Adding a call to addsitedir won't accomplish your stated goal of > dropping eggs into lib/python and having them get used. For addsitedir > to have any impact, you have to also manage the .pth files. The fact > that you "requently get lost between sys.path, sys.prefix, .pth files > and the site.py module" is not at all surprising. There is a lot > of magic there. We certainly don't want to toss any of this in at the > last hour (I wish) of a release. I wasn't actually pushing for this to be added to the 3.3 release. (As for the release target, a beta2 would be nice as a first step). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: eggs in a Zope 3.3 instance
On Jun 24, 2006, at 3:38 AM, Philipp von Weitershausen wrote: Jim Fulton wrote: Concretely, what do you think about making lib/python in a Zope 3.3 instance a site for now (calling site.addsitedir())? I think it's a bad idea, mainly because it's too late to make such a change for 3.3. I tell you what I will do though, I'll promise, by the end of EP, to have a buildout that lets you define Zope 3.3 instances with the eggs of your choice. That sounds very interesting. However, zc.buildout is clearly aimed at large deployment. A *simple* way of deploying eggs in instances would still be needed (*I* need it, in fact); I'm confident that zc.buildout will serve simple cases well. The zc.buildout project itself *is* an example of a simple buildout and I think it is serving itself rather well. :) if not in Zope 3.3, then at least later. Currently you only have to drop package directories into INSTANCE/lib/python, something similar with eggs should also be possible. I frequently get lost between sys.path, sys.prefix, .pth files and the site.py module. The fact that a one line fix gets what we want seems simple enough to me. As said, I'm not the expert here, though :) I doubt we are going to make our release target as it is. I don't think any feature change, especially one with such far reaching ramifications is justified. Adding a call to addsitedir won't accomplish your stated goal of dropping eggs into lib/python and having them get used. For addsitedir to have any impact, you have to also manage the .pth files. The fact that you "requently get lost between sys.path, sys.prefix, .pth files and the site.py module" is not at all surprising. There is a lot of magic there. We certainly don't want to toss any of this in at the last hour (I wish) of a release. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://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
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton
The Buildbot has detected a failed build of Zope3 trunk 2.4 FreeBSD tmiddleton. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6312 Blamelist: hdima,jens BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] buildbot failure in Zope3 trunk 2.4 Linux tlotze
The Buildbot has detected a failed build of Zope3 trunk 2.4 Linux tlotze. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6312 Blamelist: hdima,jens BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: SVN: Zope3/branches/3.3/ Fixed issue 525: DateWidget ru-format
Dmitry Vasiliev wrote: > Log message for revision 68818: > Fixed issue 525: DateWidget ru-format ... > Modified: Zope3/branches/3.3/src/zope/formlib/form.txt > === > --- Zope3/branches/3.3/src/zope/formlib/form.txt 2006-06-24 09:00:09 UTC > (rev 68817) > +++ Zope3/branches/3.3/src/zope/formlib/form.txt 2006-06-24 09:02:44 UTC > (rev 68818) > @@ -1554,7 +1554,7 @@ > size="10" type="text" value="" /> > - type="text" value="2002-12-02 12:30:00" /> > + type="text" value="2002 12 2 12:30:00 " /> > > Note that a EditForm can't make use of a get_rendered method. The > get_rendered > method does only set initial values. Why does the display of the default DateTime widget change? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: eggs in a Zope 3.3 instance
Jim Fulton wrote: >> Concretely, what do you think about making lib/python in a Zope 3.3 >> instance a site for now (calling site.addsitedir())? > > I think it's a bad idea, mainly because it's too late to make such a > change for 3.3. I tell you what I will do though, I'll promise, by > the end of EP, to have a buildout that lets you define Zope 3.3 > instances with the eggs of your choice. That sounds very interesting. However, zc.buildout is clearly aimed at large deployment. A *simple* way of deploying eggs in instances would still be needed (*I* need it, in fact); if not in Zope 3.3, then at least later. Currently you only have to drop package directories into INSTANCE/lib/python, something similar with eggs should also be possible. I frequently get lost between sys.path, sys.prefix, .pth files and the site.py module. The fact that a one line fix gets what we want seems simple enough to me. As said, I'm not the expert here, though :) Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
