I am writing capybara tests. There is a link I have in the view. When I click over the link that links open a pop-up js warning. I have configured Js. in capybara by using phantomjs and petergiest gem.
Without the requested information it's impossible to give an exact answer, but the error you are seeing means the app is requesting a non-JS response (probably HTML). This could be occurring for a couple of reasons
You're not actually running the test with a JS supporting driver. I don't see any js metadata on your scenarios so depending on how you've configured Capybara/RSpec this could by your issue. To confirm, swap from Poltergeist to using Selenium with Chrome or Firefox (non-headless while trying to debug) so you can see if the browser actually starts
You have a JS error preventing JS from running so a normal request is being made instead of XHR. This could be because you actually have a bug in your JS or because you're using Poltergeist/PhantomJS which is massively out of date in JS/CSS support. To test this, swap to using Selenium with Chrome or Firefox and look in the developer console.
Your link isn't correctly configured to make an ajax request - This is impossible to tell without the HTML of the link
Additionally, neither of the tests shown in your image are actually asserting/expecting anything so it's very unclear what exactly you're trying to test.
Related
I use wicked (1.3.1) (not sure if relevant) for an onboarding flow on my rails 5 app. On the last step of my onboarding process, there is an <a> link that navigates to a user#dashboard page.
This works totally fine in all browsers. For some reason that transition does not work in Capybara (rspec 3.7, rspec-rails 3.7.2, Capybara 2.14). The url changes in the automated browser to the desired route, but the page does not render any content, it retains the old view. Visually its as if someone typed in a url but did not press return, however, the controller method and view are getting touched when i debug them. They appear to return a rendering, but the value is not rendered in the browser
If i throw a sleep in my test after the <a> click, I can manually click on the url bar, press return (to navigate to the correct url) and the page will render then. But not on its own. Anyone experience this before?
I have tried changing the href to a different path to see if it is a problem with the target view/controller - it is not, happens to all of the paths I try. I have also tried different capybara drivers: :selenium, :chrome, :poltergeist. All same result!
Would love to provide more detail but i'm not sure what to show. Its a simple href and i'm not sure what could go wrong.
Cheers
EDIT:
turns out there was an error in the logs. Will update with a solution.
error:
Could not log "render_template.action_view" event. NoMethodError: undefined method `render_views?' for RSpec::ExampleGroups::LayoutsSplash::View:Class ["/Users/mitchellmeyer/.rvm/gems/ruby-2.3.1/gems/rspec-core-3.6.0/lib/rspec/core/example_group.rb:732:in `method_missing'",
The error shown in the logs is a know rspec/rspec-rails 3.6 issue - upgrading will fix that. Beyond that, the fact it works when a URL is submitted manually to the browser but not when clicking on the link indicates the link is probably being interfered with by JS. Most likely that's Turbolinks which you can disable for a given link by adding a data-turbolinks=“false” attribute to the link. If that fixes the behavior (which you state it did) then it's probable you have a JS error in one of your files. Check the developer console in the browser for any errors shown and fix them.
Since you mention Poltergeist, as a driver you tried, in your question it's possible for there to be silent errors that cause JS to fail when using it since it doesn't support anything beyond ES 5.1 so it's not really that suitable for testing modern webapps any more and I would recommend sticking to headless chrome if you need headless testing.
I am trying to write some integration tests in rspec/capybara/selenium for my Rails 5 app. I have recently started testing some javascript features in the app with headless Chrome.
I struck a problem where I was unable to choose a select element on the page with capybara despite this working fine when I loaded the site manually in chrome in development environment. After some investigating I figured out that the select element was not currently visible. It is hidden when the page loads but should then be made visible immediately on loading by my javascript.
I disabled headless and paused my test with a quick and dirty sleep 60. I then looked at the javascript file in Chrome's developer tools and discovered that it has loaded an old version of the file with none of my recent changes. The file it has loaded no longer exists in my app so it must be being cached somewhere. Any ideas how this might be occurring and how I can fix it?
I've just started writing integration tests with Capybara and I am running into the following symptoms after successfully accessing a page.
#response.body shows the correct HTML as expected.
page.body shows nothing.
save_and_open_page saves the file but the file is empty.
click_on("#item") fails (note I can see it in #response.body). Many other types of CSS access also fail here.
I surmise that Capybara failing to access known CSS is related to its rendering a blank page. Is there an underlying reason for all this behavior?
You need to use #visit to have Capybara go to a page. Capybara is designed to emulate a user using a browser - it has no support for direct get/post/put... since a user doesn't have that. It also has no direct access to the response from the app, since the browser handles that. What it does let you do is move around the app, in a browser, like the user would and then assert against elements of the page appearing, disappearing, and displaying expected information
I'm running Firefox 36.0.4 on Windows 7 32-bit. I've diabled all add-ons, extensions and user scripts before retesting this.
I'd like to step through JavaScript code that is served up in a <script> tag in the HTML document being produced by a Java (Tomcat) web server.
Unfortunately, when I select the HTML document under Debugger > Sources, the source of the page returns to the login page of the application - it appears that session information is not being used to request the source.
I stepped through the server-side code and found that the correct session cookie values were being sent for the real page request and some AJAX requests sent by the page. However, when I tried to load the page source in the JavaScript debugger, I found that an incorrect session cookie was being sent by the JavaScript debugger.
I can replicate this behaviour in other webapps, not just my own. For example, Stack Overflow:
Is this a configuration issue, or a bug in the Firefox Developer Tools?
I can't reproduce your problem using StackOverflow as an example, at least in Firefox Developer Edition ( currently version 38 ):
One thing that might help - try disabling the cache while the toolbox is open - this setting is in the developer tools setting panel ( click on the 'gear' icon at the top right of the toolbox ):
After reviewing canuckistani's answer, I downloaded Firefox Developer Edition. Seemingly, the problem was fixed.
Five minutes in, I became sick of being asked whether to remember passwords and having to manually clear session cookies (I prefer being able to do it by simply closing the browser) - it makes testing easier.
As per usual, I went to Options > Privacy > History to disable this behaviour, by setting the value to Never remember history.
Changing this setting requires the browser to restart. However, upon restarting, I once again saw the same erroneous behaviour - the wrong session cookie was being sent to the web application again.
The workaround here is to not use the Never remember history setting. I have filed a bug report at Mozilla.org Bugzilla.
Is there an "Angular/Dart" way to detect older unsupported browsers and prevent to continue with an elegant message (there are plenty of examples using javascript) rather than continue and show a weird layout with code that doesn't work?
Even the angulardart.org/demo site should do this IMO to stop IE8 (I know, but some enterprise customers still have those old browsers installed - and set as default - for legacy apps) from showing content that doesn't even work.
If Dart code cannot be executed the test has to be done in Js. I'm not aware of a library that makes this test.
The test should follow What browsers do you support as JavaScript compilation targets?.