Permalink
Browse files

Refer to has_content rather than has_text for now

This way users of Capybara 1.1.2 will not be confused. We could start
preferring has_text in the README once 2.0.0 is out.

@hardbap in #580 and @mipearson in #604 ran into this -- thanks to
both for the reports!
  • Loading branch information...
joliss committed Jan 10, 2012
1 parent 6446d74 commit bf748fd67f6e665d58b562ca84f0aa4630a6a80f
Showing with 4 additions and 4 deletions.
  1. +4 −4 README.md
View
@@ -376,7 +376,7 @@ page.has_no_selector?(:content)
page.has_xpath?('//table/tr')
page.has_css?('table tr.foo')
-page.has_text?('foo') # synonymously: page.has_content?('foo')
+page.has_content?('foo')
```
**Note:** The negative forms like `has_no_selector?` are different from `not
@@ -391,7 +391,7 @@ page.should have_no_selector(:content)
page.should have_xpath('//table/tr')
page.should have_css('table tr.foo')
-page.should have_text('foo')
+page.should have_context('foo')
```
### Finding
@@ -534,7 +534,7 @@ When issuing instructions to the DSL such as:
```ruby
click_link('foo')
click_link('bar')
-page.should have_text('baz')
+page.should have_content('baz')
```
If clicking on the *foo* link triggers an asynchronous process, such as
@@ -574,7 +574,7 @@ Capybara's waiting behaviour is quite advanced, and can deal with situations
such as the following line of code:
```ruby
-find('#sidebar').find('h1').should have_text('Something')
+find('#sidebar').find('h1').should have_content('Something')
```
Even if JavaScript causes `#sidebar` to disappear off the page, Capybara

1 comment on commit bf748fd

@joliss

This comment has been minimized.

Show comment Hide comment
@joliss

joliss Aug 21, 2012

Collaborator

I wrote:

Refer to has_content rather than has_text for now

This way users of Capybara 1.1.2 will not be confused. We could start
preferring has_text in the README once 2.0.0 is out.

I'm actually thinking we should keep has_content, since the semantics are very close to 1.1.2, and using has_content makes it possible to downgrade to 1.1.2 if you encounter some hitch in 2.0. (2.0 is surprisingly backwards-compatible.)

Collaborator

joliss commented on bf748fd Aug 21, 2012

I wrote:

Refer to has_content rather than has_text for now

This way users of Capybara 1.1.2 will not be confused. We could start
preferring has_text in the README once 2.0.0 is out.

I'm actually thinking we should keep has_content, since the semantics are very close to 1.1.2, and using has_content makes it possible to downgrade to 1.1.2 if you encounter some hitch in 2.0. (2.0 is surprisingly backwards-compatible.)

Please sign in to comment.