selenium2library - "Element Should Contain" keyword, but no "Element Should Not Contain" keyword?

[WillDev Dev]

Per the official keyword listing -

http://rtomac.github.io/robotframework-selenium2library/doc/Selenium2Library.html#Element Text Should Be

Usually keywords have a "should be" and a "should not be" variation. For example, "Element Should Be Visible" and "Element Should Not Be Visible".

I've been writing tests to test that certain error messages do show up, and other error messages do not show up. Testing they are there goes fine, but writing a test that an error message is not there is a problem. Is there any "Element Text Not Should Be" keyword I might be unaware of?

[WillDev Dev]

P.S. I found a workaround, but it would still be much easier to just use the keyword directly -

• ${textFromErrors} Get Text ${newDiscountErrorsTextId}
  
• Log Check that previous text does not contain any errors for the "name" field
  
• Should Not Contain ${textFromErrors} Name Error messages included (but should not have) a message about the "name" field. Test Failed.
  

[Tatu Aalto]

Ugh

Sometimes I have also a need for the *not found* keywords.  Also I have ended up writing a similar workaround. Perhaps enhancement request should be written?

-Tatu

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at http://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Kevin O.]

The Java port has a Element Should Not Contain keyword, but the Python version is still lacking it.

There is already an issue for this. I have also used a workaround similar to yours.

Pull requests with unit and/or acceptance tests tend to get things like this implemented quickly. Selenium2Library does not have corporate sponsorship like RF & RIDE do AFAIK.

[Pekka Klärck]

2013/12/11 WillDev Dev <will...@gmail.com>:

> P.S. I found a workaround, but it would still be much easier to just use the
> keyword directly -

You definitely should create a new user keyword that you can reuse easily:

*** Keywords ***
Element Should Not Contain
[Arguments] ${locator} ${text}
${content} = Get Text ${locator}
Should Not Contain ${content} ${text}

I do agree that "Element Should Not Contain" could be added to Se2Lib
too. The above approach could still be used if you needed something
like "Element Should Match Regexp" or "Element Should Not End With".
Adding all such keywords to Se2Lib definitely makes no sense.

Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org

[Pekka Klärck]

2013/12/11 Kevin O. <korm...@gmail.com>:

> Pull requests with unit and/or acceptance tests tend to get things like this
> implemented quickly.

Yes, this is typically the fastest way to get new features and also
fixes into open source projects in general. Alternatively you can
obviously pay someone to do the work for you.

> Selenium2Library does not have corporate sponsorship like RF & RIDE do AFAIK.

RF and RIDE do have corporate sponsorship, but even with them getting
new features in is faster if you provide patches (or money). The team
working for NSN obviously cannot spent too much time implementing
features that are not important for organizations/teams working for
NSN. We try to get all bugs fixed regardless the source they are
reported, though.