I want to write test cases for my rails application. I have already written a lot of test cases in Rails built-in framework Minitest.
Now I want to test javascript functionality of my web app.
I came across these two tools
1: Selenium web-driver
2: Capybara-webkit
I am confused which one to use. I know few advantages and disadvantages of these two tools like
Capybara webkit is headless while selenium web-driver open a browser.
Capybara is faster than selenium.
Capybara cannot open any other application while selenium can interact with third party apps like facebook and LinkedIn
Can anyone tell me the comparison of these two tools for testing ?
You're confusing a few things here. Capybara is a testing framework/DSL, for Ruby, which can be used with any of the test runner frameworks (RSpec, Minitest, etc). It can use a number a of different drivers to communicate with the web app being tested.
The default driver is rack_test which doesn't support any JS and cannot connect to any addresses outside the app under test.
A second driver option is selenium-webdriver which can control multiple different real browsers firefox/chrome/safari/etc. for testing, and can connect to any valid URL. The downside of using selenium-webdriver as the driver is that it opens a real browser and is therefore usually slower with a larger memory footprint.
Another driver option is capybara-webkit which is headless and can also connect to any valid URL. It is generally faster than using selenium however as it is built on an old version of QtWebkit it doesn't support newer web standards (ES2015, etc) so at a minimum you need to make sure all JS is transpiled to ES5 maximum.
There is nothing to stop you using different drivers for different tests to get the benefits of speed for most tests and then use a real browser for tests that need things like WebRTC, etc. The Capybara README details how to do that when using different test runners (RSpec, Minitest, etc)
Related
We have used React JS for front end and we need to write end to end tests. After researching online, we came across 2 options :
1. Selenium WebDriver
2. React Test Utils (https://reactjs.org/docs/test-utils.html)
What I understood was that with React Test Utils you can simulate clicks and check the status of the HTML elements by using methods like findRenderedDOMComponentWithXXX and that you can run these tests from command line so they will be faster.
Selenium does the same thing but from within the browser, it will allow you to write test in Behavior Driven Development Style(making it more readable)
My confusion :
Can we use React Test Utils to test a complete web page (complex component) or it is better to only test simple custom made components.
For example: If we have a component like Tasks which allows you to
add tasks, remove tasks, change priority which uses components like Input, DropDown and Toggle.
So is it a good idea to use React Test Utils for the entire Tasks component or we should use it for smaller inidividual components like Input, DropDown, Toggle
To test the complete Tasks component write end to end tests using Selenium.
Some other points :
simulate method in React Test Utils requires to pass event data which can increase small amount of work.
It will be great if some one can help me understand the difference between two.
You can use Jest and Selenium together. Don’t limit yourself to just one. You probably will go even beyond those two when you do Test Driven Development, or even Behavior Driven Development, based on what specifically you need to test. Jest by itself can’t really simulate UAT in my opinion. You need to open the browser to fully simulate the user experience, but those browser tests could be a very small percentage of tests relative to all of your tests. The reason why so many people have moved away from selenium is the bulkyness of configuration and maintenance of it. Also speed and reliability.
There are newer tools coming to life for browser based testing in recent years:
Puppeteer
https://github.com/GoogleChrome/puppeteer
Nightwatch.js
http://nightwatchjs.org
Also, your specific programming language offers additional features and enhancements to testing. Many Java developers use Maven and TestNG with their testing to build and debug their tests. Ruby developers might use RSpec. Whatever test runner you use, it might incorporate several dependencies on the backend for all kinds of testing tools for linting, html proofing, functionality, DevSecOps, database migrations, or even spellcheck. The key is to group all the tests you think you will need together in a single test runner (preferably, or as few as possible). Then run them all, back to back in a CI/CD pipeline; like Jenkins prior to deployment of changes. If any one fails, then your build fails in real time.
If you want to run several API tests in the pipeline, Newman is looking pretty decent to incorporate Postman tests you may already have laying around into a CI/CD pipeline. Of course alternatively, you could also build http clients, but not everyone has a coding skill set, so the tools you pick first should compliment the skillsets you have available to you as well.
Smart Bear also has several tools now that will run in a CI/CD pipeline for SOAP and UI testing, but those are much more expensive than the open source alternatives.
What options do I have to performance test an Electron application in a similar way to how Load Runner does it?
I need to performance / load test an Electron application built using React. The application is deployed to Windows 7 (possibly to Windows 10 as well) and invokes ReST APIs.
I'm aware of the Spectron option but it doesn't sound like it is automated out of the box. I'd prefer to use a framework that already provides recording, playback, response time metrics, and configuring multiple scripts.
Many thanks in advance
REST means HTTP so you need a performance testing tool which supports recording HTTP traffic.
The majority of performance testing tools provide TCP or HTTP proxy server for capturing the traffic and converting it into internal form of tests
Assuming above 2 points you need to:
Choose a performance testing tool which suits your needs
Configure your Electron application to use the selected tool as a proxy, your application either has its own proxy settings or respects underlying operating system proxy setup.
This way your Electron application will communicate with the backend via performance testing tool proxy which will be capturing requests so you will be able to replay them with increased load later on. Check out How to Run Performance Tests of Desktop Applications Using JMeter for example instructions.
We are building a responsive Ecommerce Website and would like to test it on several mobile devices on cloud. There are so many of them like AWSDEvice Farm, Sauce Labs, CrossBrowserWeb Testing etc.
We need the tool to perform some manual tests on real devices as well as run our Automated Selenium Scripts on real device.
Any thoughts or advice which ones are better from the ones mentioned above
Thanks
QA
That's really hard to answer as it comes down a matter of opinon and all the specs of the project.
I don't know about the other but device farm has you upload the test package which can only be a appium java testng/junit or python pytest package. Then in the public offering it will find a device and run the tests which may take longer than other options because it restarts the appium server between tests.
In the private offering for device farm, we can use direct device access to run any testing framework we want. However, the up front cost for these is more than the public offering.
You are also limited in the execution time. Right now we can only run the tests up to 150 minutes.
Hope that helps
James
Running Selenium tests having dependency to few Physical Network devices, parallely using TeamCity / CI.
Hi Guys,
I would like to run Selenium Cucumber tests JAVA-Maven using TeamCity;
We could create few maven profiles, which in turn calls set of Cucumber Test Runners.
Could you please suggest how we can achieve parallel execution using TeamCity Instances / multiple TeamCity nodes, which will correspond to categories of mentioned bespoke devices.
Without TeamCity mulitiple instances I would achieve this in following way:
Create Set of Cucumber Test Runners
Categorise them based on type of devices
Call the test runners using Maven profiles
Achieve the parallelism using maven-surefire plugin.
Maintain the active set of devices using runtime JSON file / POJO.
But kindly advise how to achieve this using TeamCity multiple agents / instances.
Many thanks
No idea how to do this in TeamCity specifically, but you may find this of use, which is a general way to run Cucumber-JVM tests in parallel using Maven. This will open multiple browsers on the same machine.
https://www.opencredo.com/2013/07/02/running-cucumber-jvm-tests-in-parallel/
If you wish to run Selenium tests across multiple machines, it sounds like what you are looking for is Selenium Grid.
My team solved the parallelization problem by using a tool that we developed and pushed to github called Zucchini. It handles the multithreading, local thread variables, and synchronization (should you need that) and has helped us scale out our tests for web, mobile and STBs nicely (especially when paired with SauceLabs)
I am looking for a general strategy to use Cucumber tests in a Linux environment to test against an Internet Explorer browser. I have seen a similar answer but that does not seem to apply to capybara 1.1.3.
I was hoping to use capybara to avoid using Selenium directly and the subsequent cost (speed, environmental dependencies) of not using headless tests, but it seems that may not be possible. I want to avoid using both capybara and selenium.
A nice compromise may be Ross Patterson's answer to a Selenium based question:
Headless browsers are a bad idea. They get you some testing, but nothing like what a real user will see, and they mask lots of problems that only real browsers encounter. You're infinitely better off using a "headed" browser (i.e., anything but HTMLUnit) on a headless environment (e.g., Windows, or Linux with XVFB).
Thanks for your thoughts.