MuraliKola / robotframework-seleniumlibrary

Automatically exported from code.google.com/p/robotframework-seleniumlibrary
Apache License 2.0
1 stars 0 forks source link

New `Xpath Should Match X Times` keyword #136

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I wrote this keyword today to test something:

There should be exactly one result
  Call Selenium API  verifyXpathCount  id('ires')//li[@class="g"]  1

It would be nice to have a Selenium Library keyword like "Page Should Contain 
Number Of Elements" that would allow me to do:

Page Should Contain Number Of Elements  id('ires')//li[@class="g"]  1

Original issue reported on code.google.com by spielman...@googlemail.com on 18 Sep 2010 at 2:23

GoogleCodeExporter commented 8 years ago
There's already `Get Matching Xpath Count` that seems to do exactly this:
http://robotframework-seleniumlibrary.googlecode.com/hg/doc/SeleniumLibrary.html
?r=2.4#Get%20Matching%20Xpath%20Count

Should it possibly be linked from some other keywords to make it easier to find?

Original comment by pekka.klarck on 18 Sep 2010 at 2:43

GoogleCodeExporter commented 8 years ago
Get Matching Xpath Count is nice, I didn't see this in the documentation. 
However, it does only one of the two steps I would like to perform: it gets the 
xpath count for the provided xpath. It doesn't verify its value though. So, the 
new keyword might look like this, in text form:

Page Should Contain Number Of Elements
  [Arguments]  ${xpath}  ${number}
  ${_number} =  Get Matching Xpath Count  ${xpath}
  Should Be Equal As Integers  ${_number}  ${number}

I've just tested this and it works just fine. I don't know yet how to express 
this in Python, but I'll try to propose a patch ;)

Original comment by spielman...@googlemail.com on 18 Sep 2010 at 3:11

GoogleCodeExporter commented 8 years ago
This is so easy to implement as a user keyword that I'm not entirely sure is a 
library keyword needed. I'm not really against adding it, though, so if you 
Robert think it's useful, please go ahead and implement it. Implementation 
should be pretty trivial but it should nevertheless get an acceptance tests. 
Can you discuss with Andreas how to create them?

Finally, I think the keyword should be named `Xpath Should Match X Times` to 
match `Get Matching Xpath Count` and `BuiltIn.Should Contain X Times`. The 
`Element Something` keywords also handle the locator differently.

Original comment by pekka.klarck on 18 Sep 2010 at 3:40

GoogleCodeExporter commented 8 years ago
I've quickly implemented a method "xpath_should_match_x_times" in assertion.py 
and added an acceptance test, please see the attached patch for details. Maybe 
the keyword should be called ".. match n times" to make it more clear that n 
means a natural number.

btw, can you tell me how to generate the documentation?

Cheers
Robert

Original comment by spielman...@googlemail.com on 18 Sep 2010 at 4:26

Attachments:

GoogleCodeExporter commented 8 years ago
The patch looks good. Few code style comments, documentation enhancement ideas, 
and other nitpicking below:

1) Use 'under_score' format instead of 'camelCase' also in variable names. We 
generally try to follow PEP 8 so you may want to study it too: 
http://www.python.org/dev/peps/pep-0008/

2) No empty lines inside methods. If a method is too long to be understood 
without them -- this one isn't -- it should be split.

3) Use 'a != b' instead of 'not a == b`. (And similarly 'a is not b' instead of 
'not a is b' if you ever need identity comparison.)

4) The expected and actual counts should probably be converted to same format 
(either str or int) before comparison. `get_xpath_count` apparently returns the 
count as a string, so if the actual value is given as a string the comparison 
works. If the actual value is given as an integer, comparison most likely 
fails. You could add this line to the current test:

  Xpath Should Match X Times  //input[@type="text"]  ${1}

In this case I wouldn't care about possible conversion errors i.e. wouldn't do 
the conversion in try/except.

5) If you change 'given xpath' -> 'given `xpath`' in the doc, the argument will 
get special formatting in the generated doc. 

6) This keyword and 'Get Matching Xpath Count' should be cross-linked. This is 
easily done by mentioning the other keyword in the doc so that its name is in 
backticks like 'See also `The Other Keyword`'. In this case something like 
below could be added to the new keyword:

   Use `Get Matching Xpath Count` keyword if you just want to get the count.

See the documentation of the libdoc.py tool for more information about 
cross-linking and formatting in general.

7) Add a note to the doc that this is a new keyword in 2.4.1 version. We 
haven't actually discussed what is the next version, but forgetting to update 
this note if we go directly to 2.5 isn't that bad.

8) Re-generate the documentation. This way you can verify that the new doc 
looks good and cross-linking works. You can also commit the generated doc in 
separately. We typically use simple message 'regen' with that kind of commits.

Original comment by pekka.klarck on 19 Sep 2010 at 9:01

GoogleCodeExporter commented 8 years ago
Thanks for the feedback! 1-3 and 5-7 are already done.

About 4: I was thinking about converting the expected_xpath_count to a String, 
but I didn't find a good way to do it. Can I use utils.unic(...) from the Robot 
Framework? Apart from the xpath code which imports utils, the Selenium Library 
code looks pretty independent from RF so I didn't dare to use an import from 
there without asking beforehand. ;)

About 8: how do I generate the docs? For RF, I used the utility scripts back 
when I worked on the docs, but I have no clue about generating the SeLib 
documentation.

Have a nice Sunday,

Cheers
Robert

Original comment by spielman...@googlemail.com on 19 Sep 2010 at 10:34

GoogleCodeExporter commented 8 years ago
Okay, I've figured out how to use libdoc. Couldn't be much easier =)

Original comment by spielman...@googlemail.com on 19 Sep 2010 at 11:01

GoogleCodeExporter commented 8 years ago
No need to use utils.unic here. It's main purposes are handling a situation 
where the given string has invalid encodings gracefully and workaround some 
Jython bugs. In normal usage you are fine with unicode or str, and in this case 
the latter is definitely enough.

Original comment by pekka.klarck on 20 Sep 2010 at 10:35

GoogleCodeExporter commented 8 years ago
Thanks - here's a new patch for review!

Original comment by spielman...@googlemail.com on 21 Sep 2010 at 6:29

Attachments:

GoogleCodeExporter commented 8 years ago
Looks fine. You could have actually already committed this in after we agreed 
that adding the keyword is a good idea. Google Code has really good review 
possibilities and it's thus easier to comment committed code than patches.

Original comment by pekka.klarck on 22 Sep 2010 at 9:26

GoogleCodeExporter commented 8 years ago
One more comment: You should add a link pointing to this new keyword to the old 
`Get Matching Xpath Count` keyword.

Original comment by pekka.klarck on 22 Sep 2010 at 9:29

GoogleCodeExporter commented 8 years ago
This issue was closed by revision d8e0ff2b8b.

Original comment by spielman...@googlemail.com on 23 Sep 2010 at 9:58

GoogleCodeExporter commented 8 years ago
I've just pushed the changesets for this issue and issue 137.

Original comment by spielman...@googlemail.com on 23 Sep 2010 at 9:59

GoogleCodeExporter commented 8 years ago
I didn't look at the final commits too closely but the original patches looked 
good. Changing status to Done, which we use instead of Fixed that is default on 
Google Code. Done works well with all issues and not just bugs.

Original comment by pekka.klarck on 23 Sep 2010 at 10:24

GoogleCodeExporter commented 8 years ago

Original comment by janne.t....@gmail.com on 12 Nov 2010 at 7:01

GoogleCodeExporter commented 8 years ago

Original comment by pekka.klarck on 16 Nov 2010 at 11:37

GoogleCodeExporter commented 8 years ago

Original comment by pekka.klarck on 16 Nov 2010 at 11:38

GoogleCodeExporter commented 8 years ago

Original comment by pekka.klarck on 16 Nov 2010 at 11:44

GoogleCodeExporter commented 8 years ago
In my script I am tring to use "Get Matching Xpath Count" but it is fatching 0 
count, though the same xpath identified with "is_element_present" from "Call 
selenium api".

I tried xPath for form,tr and div

Whereas the //input is working fine and giving expected value.

Original comment by chetan.d...@gmail.com on 3 Nov 2011 at 11:27

GoogleCodeExporter commented 8 years ago
Why is this method only take the expath starting from "//"?

Ex:  Xpath Should Match X Times  //input[@type="text"]  ${1}

Whereas other functions support xpths to be provided starting with "//" and 
"xpath=//".

Ex:Element Should Be Visible

Either:
${PATH} //input[@type="text"]
Element Should Be Visible ${PATH}

Or:
${PATH} xpath=//input[@type="text"]
Element Should Be Visible ${PATH}

Original comment by asanke.g...@gmail.com on 29 Mar 2014 at 6:39