mirror of
https://github.com/teamcapybara/capybara.git
synced 2022-11-09 12:08:07 -05:00
Merge pull request #482 from adamlogic/readme_fix
Remove statement about should_not have vs should have_no
This commit is contained in:
commit
1b6dca33d4
1 changed files with 10 additions and 5 deletions
15
README.rdoc
15
README.rdoc
|
@ -498,14 +498,19 @@ is (the default is 2 seconds):
|
|||
Be aware that because of this behaviour, the following two statements are *not*
|
||||
equivalent, and you should *always* use the latter!
|
||||
|
||||
!page.has_xpath?('a')
|
||||
page.has_no_xpath?('a')
|
||||
|
||||
The former would immediately fail because the content has not yet been removed.
|
||||
Only the latter would wait for the asynchronous process to remove the content
|
||||
from the page.
|
||||
|
||||
Capybara's Rspec matchers, however, are smart enough to handle either form.
|
||||
The two following statements are functionally equivalent:
|
||||
|
||||
page.should_not have_xpath('a')
|
||||
page.should have_no_xpath('a')
|
||||
|
||||
The former would incorrectly wait for the content to appear, since the
|
||||
asynchronous process has not yet removed the element from the page, it would
|
||||
therefore fail, even though the code might be working correctly. The latter
|
||||
correctly waits for the element to disappear from the page.
|
||||
|
||||
Capybara's waiting behaviour is quite advanced, and can deal with situations
|
||||
such as the following line of code:
|
||||
|
||||
|
|
Loading…
Reference in a new issue