I'm using Capybara 2.1 with Ruby 1.9.3 using the selenium driver (with Minitest and Test Unit) in order to test a web app.
I am struggling with the StaleElementReferenceException problem. I have seen quite a number of discussions on the topic but I haven't been able to find a solution to the issue that I am facing.
So basically, I'm trying to find all pagination elements on my page using this code:
pagination_elements = page.all('.pagination a')
Then I'm doing some assertions on those elements like:
pagination_elements.first.must_have_content('1')
After those assertions, I'm continuing the test by clicking on the Next Page link to make sure that my future first pagination element will be the Previous Page.
To do that I'm retrieving paginations elements again :
new_pagination_elements = page.all('.pagination a')
And the Stale Error is occurring here, because I'm reaching elements that I've already reached. ( Here is the error )
You can see the link states here.
I really have no idea how to make this common test work properly.
Do you have any tips for a better way to reach my pagination elements?
I sometimes have some problem with AJAX intensive pages, in my case this workaround solves it:
begin
...
rescue Selenium::WebDriver::Error::StaleElementReferenceError
sleep 1
retry
end
I saw the main message in the gist is:
Element not found in the cache -
perhaps the page has changed since it was looked up
I have similar case before. There are two solutions:
Add page.reload before checking same stuff in new page, if you have set Capybara.automatic_reload = false in spec_helper
find a special element in new page which previous page doesn't have. This effect is equivalent to wait.
Another method is to use specific selector. For example, instead of
pagination_elements = page.all('.pagination a')
Use
pagination_elements = page.all('#post_123 .pagination a')
Append a unique id area to the selector and you should not meet such problem.
Interesting link about this error and how to fix it : http://stefan.haflidason.com/testing-with-rails-and-capybara-methods-that-wait-method-that-wont/
Apparently, in addition to race conditions, this error also appears due to misused within blocks. For example:
within '.edit_form' do
click '.edit_button'
# The error will appear here if the 'edit_button' is not a
# descendant of the 'edit_form'
end
HAve you tried to use WebDriver directly rather than via Capybara? This woudl potentially give you more control of when to and when to not cache objects.
e.g. (Apologies for the java syntax but should get the idea)
WebElement searchField = driver.findElement(By.CssSelector("input.foo"));
searchField.click();
searchField.sendKeys("foo foo");
System.out.println(searchField.getText());
//Do something elsewhere on the page which causes html to change (e.g. submit form)
.....
....
//This next line would throw stale object
System.out.println(searchField.getText());
//This line will not throw exception
searchField = driver.findElement(By.CssSelector("input.foo"));
System.out.println(searchField.getText());
Assigning "findElement" again to "searchField" means that we re-find the element. Knowing when to and when not re-assign is key went deciding how to cache your webelements.
I have not used Capybara, but I assume that it hides the caching strategy from you?
Related
I am trying to write an integration test in which I must check the visibility of an element on button click. The code works perfectly in one machine and failing in the other. The element is displayed until the data comes from the backend. So its visibility depends on the speed of the machine also. Is that the problem? This is the code:
assert page.has_css?('#my_element_id')
assert find('#my_element_id', visible: true)
But I am getting an error: expected false to be truthy.
Is there any other way to assert the visibility of the element?
You can also try:
assert find('#my_element_id').visible?
from: https://rubydoc.info/gems/capybara/0.4.0/Capybara/Element#visible%3F-instance_method
It does say however:
visible? ⇒ Boolean
Whether or not the element is visible. Not all drivers support CSS, so
the result may be inaccurate.
I assume you are talking about whether #my_element_id is visible.
EDIT:
If you are waiting for an element to be visible first before checking for the element with the id #my_element_id this posts might be helpful:
How to make Capybara check for visibility after some JS has run?
So you could wait for the backend data to come through then check visibility. If you are try to check that it is visible before that data, I am not quite sure, it seems like it would depend on the machine's internet connection to me.
Don’t use plain assert, use the assertions provided by Capybara which include retrying behavior
assert_css(‘#my_element_id’)
By default that would check only for visible elements, but if you’ve set Capybara.ignore_hidden_elements = false (don’t do that, really dont) then you would need to also pass the :visible option
Note: you may still have issues if it’s only visible for a very short time - in that case if you’re using Chrome you can set the network conditions to very slow in order to increase the time data takes to return
we're currently working on a piece of mapping software, where we use Leaflet with custom left and right sidebars as well as a text-filter where we filter for different POI features. The whole thing looks like this:
The flow is as follows
A user visits a map under a unique link
The controller renders the HTML template first (no data is bein published)
Inside our javascript an ajax call fetches the data and renders markers, some panels, etc., etc.
We use capybara with poltergeist for all our feature tests.
In our master everything is working as it should be.
In another branch I added password protection, hence a bootstrap modal pops up if a map is password protected and has not yet been unlocked within the current session.
Everything is working fine except for some feature tests that fail lately and after messing around with stuff I still don't have a clue why exactly.
Let's see for example this test
feature 'Places map filter', js: true do
before do
#map = create :map, :full_public
create :place, :unreviewed, categories: 'Playground', map: #map
visit map_path(map_token: #map.public_token)
find('.open-sidebar').trigger('click')
end
scenario 'Nothing filters nothing' do
show_places
show_events
show_places_list_panel
expect(page).to <...>
end
...
end
Capybara claims to be unable to find some css elements. Calling screenshot_and_open_image reveals that it is still showing an overlay (hiding everything else) until all data have been loaded. Something seems to be hanging within my Javascript...
.
I've been messing around with the test-environment, which had an effect:
config.action_controller.asset_host = "file://#{::Rails.root}/public"
config.assets.prefix = 'assets_test'
The test passes since the data is now there. A screenshot reveals missing assets, which is guided by a proper warning message Not allowed to load local resource: <path>. I'm puzzled since querying the data happens via an ajax-call from one of the files that capybara tells to be unaccessible.
I don't know how to continue, since I don't want to start skipping tests. I hope you can help guiding me finding the error.
Thanks in advance,
Andi
Update
Thanks to Thomas for his hint on ES6 features. I used poltergeist's inspector mode and hence was able to discover an arrow function I introduced! That's why the JS driver couldn't deal with a callback I was passing to a promise which did not resolve...
Firstly, ensure you have js_errors: true in your Poltergeist driver registration - https://github.com/teampoltergeist/poltergeist#customization - so that you will get runtime JS errors reported.
Secondly, if you're using any ES6+ features in your JS code, make sure you transpiling them into ES5 compatible code since Poltergeist/PhantomJS only supports JS <= ES5, and will silently fail at JS parse time if it parses JS using features like let.
And finally, by using trigger you are bypassing Poltergeists checks that the button is actually clickable by the user, so make sure you're not clicking a button too early (before whatever behavior gets attached to the button is actually attached)
I have trouble with using capybara to test tinymce form. I'm using tinymce-rails and have 7 editors in my form. Also I'm using asciimath plugin with tinymce.
Everything works fine, but I'm unable to write tests to fill in tinymce editor.
Here is how my step definition code looks like, very similar to what is described here:
within_frame("content_ifr") do
editor = page.find_by_id('tinymce')
editor.native.send_keys 'test'
end
The problem is when I run the following:
editor.native.clear # works, clear the editor area, I'm testing this with pry
editor.native.send_keys :tab # works, moves focus to next input
editor.native.send_keys 'test' # returns "", nothing happens, nothing in editor
So clear and send_keys :tab work as expected. But I can't send any string. send_keys function is always returning empty string, and nothing happens when I do test using pry.
What is going wrong here? and how can I debug / investigate the problem?
Thanks.
I know that this is an old question but I just found it while trying to solve this issue as well.
Although the original question said that he has 7 tinymce's on the same page I think that my solution might work for him too but I do know it will work if there is one tinymce as was my case.
In my request spec I used this:
page.execute_script('$(tinymce.editors[0].setContent("my content here"))')
The page.execute_script with tell it to run the jQuery function. It then finds the first tincymce editor and sets the content.
Worked like a charm for me. I think if there are more than one tinymce it can be called by its position.
Switching to chrome as described here solved my problem.
Obviously the problem is related with a bug in firefox driver.
Still i think it is a valid question for firefox.
Try to switch to an iframe that contains tinymce textarea input, and than send_keys:
# +session+ is an instance of Capybara::Session class
browser = session.driver.browser
browser.switch_to.frame(iframe_id)
editor.native.send_keys(text)
browser.switch_to.default_content
I had the same issue. After a day fighting, my tests finally passed.
The code that I am using is:
within_frame("producto_condiciones_ifr") do
editor = page.find_by_id('tinymce')
editor.native.send_keys 'filling text'
end
The first line is a method of capybara. The parameter passed is the ID of the iframe.
Line #2 is a must.
In line #3 goes the text that you wish to place inside TinyMCE
just came across this problem with RoR and rspec
I managed to solve by doing this:
within_frame { page.find_by_id("tinymce").set("new content here") }
the set method will replace any existing content by the new one
if you want to keep the current content and add things to it, use the send_keys method
In a view file I have:
= link_to 'View', post
= link_to 'View', comment
In a spec file (I'm using Capybara):
click_on 'View'
It clicks on the first link, but I want it to click on the second one. How can I do it?
You could try to find all entries and deal with an array:
page.all('a')[1].click
Would help to have a class or use within to scope your search ;)
There's probably a few ways but I usually scope something like this.
within(".comment") do
click_on("View")
end
There's quite possibly/probably alternatives as well. I usually do my acceptance testing from cucumber, so my steps typically look like
When I follow "View" within the comment element
Where I have a step that translates within the comment element to a scoped call to the step itself (which I think is built into the latest capybara web_steps)
The worst thing about "the second" link is that it can become the third or the first or even the twenty fifth someday. So, scoping with a within block is the best way. Example:
within(".comment") do
click_on("View")
end
But if it is difficult to specify the link with a within scope (which sometimes it really is), I guess the way to click the second link with a certain text is:
find(:xpath, "(//a[text()='View'])[2]").click
In later versions of capybara (2.0.2, for example) both click_on 'View' and click_link 'View' will raise an ambiguous match error:
Failure/Error: click_on 'View'
Capybara::Ambiguous:
Ambiguous match, found 2 elements matching link or button "View"
So this won't do even if you want to click the first link (or if any link would be ok, which is my case).
As far as I understand this is made to force people write more specific tests where particular links are clicked.
It definitely could be tricky to debug the code if you accidentally placed two or more links with identical text and try to see what is happening. It's good to rely on something that is unlikely to change and specifying a link with a within block is a nice way to do this.
There are many ways for solving this type of problems.
Do it like this
if(page.find("a")[:href] == "comment")
click_on("View")
or
page.find("a:eq(2)").click
Remember javascript indexing starts with 0 while In Capybara, indexing starts with 1. So use a:eq(2) here for second href.
For capybara 2 solution:
within(".comment") do
click_on("View")
end
would not help if you have a few .comment. So simple use: page.first(:link, "View").click
This works for me if you have several rows of identical classes and you want to find the second row. Like a previous author mentioned, capybara indexing starts at 1.
within all(".trip-row")[2] do
assert page.has_content?("content")
end
If you use capybara-ui you could define the widget, or reusable DOM reference, for each widget.
# define your widget. in this case,
# we're defining it in a role
widget :view_post, ['.post', text: 'View']
widget :view_comment, ['.comment', text: 'View']
# then click that widget in the test
role.click :view_post
role.click :view_comment
Long title, I know but I searched all over and couldn't find that error message coming from that function call so I thought this might be more useful.
This is the code snippet:
string hql = " from LabRequest r where 1 = 1 ";
hql += " and 0 < (select count(rs) ";
hql += " from r.Statuses rs ";
hql += " where rs.StatusType.Description IN ('Assigned','Submitted')";
hql += " ) ";
//Session.Clear();
IQuery query = Session.CreateQuery(hql);
IQueryable<LabRequest> requests = query.List<LabRequest>().AsQueryable<LabRequest>();
This is a function (or most of it) in my Data Access Object in an MVC app I'm working on. It's for a search page and when the page runs this function gets called exactly like you see in the code and works.
Then, without changing anything, I refresh the page which goes through the same steps and calls this code, exactly as you see it, again. But the second time through it crashes on the query.List() portion of the last line with the error in the subject.
Session is defined in another DAO as:
session = NHibernateHelper.GetCurrentSession();
I know this is hard to analyze without the actual DB but I just wanted to see if anyone could maybe point me in the right direction, or maybe point out something obvious about NHibernate since I know basically nothing about it.
Edit: forgot to mention that when I uncomment the Session.Clear() it works fine, so was thinking the answer has something to do with that, and if it does how I should handle when to clear()?
Edit 2: This is part of the answer, but I call a very similar function prior to this one the second time around. What I can't figure out is why that one is affecting the one I posted. The 'query' variable is local, so it seems to be something with Session.CreateQuery. Anyone know what that would be?
Thanks,
Jeff
While I'm not sure why exactly it seems the 'Statistics' property on the Session has data on it from the first query and I think this is what's causing the error because if I do a Session.Clear it removes the collections in the Statistics property.
As my current, and possibly temporary fix, I just created an extension method for the CreateQuery function that takes a bool asking whether to clear the Session and am just using this instead of the one provided.
If anyone else has any real answer to this please add it.
Relating to your "Edit 1" and "Edit 2" notes, yes, it has to do with the session that is shared (assuming you're using one of the standard methods of handling sessions in NHibernate).
Is there a good reason for using Session.Clear()? In general, Clear is only used after a flush, to make sure the Session cache doesn't get too big causing a performance hit. Are you using it that way, or for some business reason not mentioned in your question?