🧐What's wrong with your current experience with rspec?
I could really go on about the pros and cons of different testing tools, but without knowing what's currently not working out for your team makes it hard to recommend something suitable for your requirements and preferences - because there's always a trade off when you pick a tool. 🙃
Before switching tools, I usually think care about what exactly do I want in my new tool. I try to resist jumping on to a bandwagon simple because it's popular. I knew what I disliked about Angular - it was hard to teach to junior devs - and picked Vue instead of the more popular React back in 2016. And recently, it turns out I didn't really like Elastic + Kibana for analytics because I want more flexibility with structuring data, so I'm trying out MongoDB Altas instead.
Figure out the following first:
Requirements:
What browsers do you want to test for now? Cypress and Puppeteer only supports Chrome.
Commitment level:
How much time does your team want to commit to creating and maintaining the tests? Selenium requires a lot of commitment to learn to write and setup and maintain the infrastructure.
Do you have time to commit to setting up pipelines to ensure tests are automatically ran? Tests that are run manually will certainly be forgotten - it's important to make sure they run automatically. Nearly all FOSS testing tools will require you to DIY integration with CI/CD. Most paid tools will offer built-in Scheduling and Monitoring capabilities.
Preference:
Does your team prefer BDD-style?
Does your team want the tests to live beside UI code in Ruby on Rails?Cabybara + RSpec is the popular choice. If your team is comfortable with Javascript, there's a lot of variety to pick from.
Other factors to consider:
How fast do you want the tests to run? Cypress is pretty damn fast, so is Puppeteer. I believe both of them utilises the Chrome DevTools Protocol instead of WebDriver protocol which makes it fast, but you'll lose some accuracy in terms of simulating actual interactions instead of syntactic interactions.
Do you want screenshots for every test and every step? Most tools require you to manually add steps to capture screenshots.
Do you want visual testing?
While @picocreator
and I are the creators of UI-licious ourselves, we won't recommend it if it doesn't suit your style. :) It's designed to be easy for non-technical folks, whilst flexible for Javascript programmers, and supports all browsers - but some folks don't like Javascript, others want tests to run blazing fast, and plenty of folks want it free. ¯_(ツ)_/¯
To add on, I've seen a lot of migration projects (for front-end, back-end, testing-frameworks) fail because the problem was the process and team capabilities/capacity, not the tools. I think it's important to really visualise the ideal workflow for the team, and then find the tool that fits. Finding the tool first and then fitting the team to the tool is like chopping the foot to fit the shoe (which is why I'm usually wary of overly-opinionated tools).
Thank you for your share, it really helped me to choose my testing tools ! I agree with you the first thing to do is to define what the team can do ...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
🧐What's wrong with your current experience with rspec?
I could really go on about the pros and cons of different testing tools, but without knowing what's currently not working out for your team makes it hard to recommend something suitable for your requirements and preferences - because there's always a trade off when you pick a tool. 🙃
Before switching tools, I usually think care about what exactly do I want in my new tool. I try to resist jumping on to a bandwagon simple because it's popular. I knew what I disliked about Angular - it was hard to teach to junior devs - and picked Vue instead of the more popular React back in 2016. And recently, it turns out I didn't really like Elastic + Kibana for analytics because I want more flexibility with structuring data, so I'm trying out MongoDB Altas instead.
Figure out the following first:
Requirements:
Commitment level:
Preference:
Other factors to consider:
While @picocreator and I are the creators of UI-licious ourselves, we won't recommend it if it doesn't suit your style. :) It's designed to be easy for non-technical folks, whilst flexible for Javascript programmers, and supports all browsers - but some folks don't like Javascript, others want tests to run blazing fast, and plenty of folks want it free. ¯_(ツ)_/¯
To add on, I've seen a lot of migration projects (for front-end, back-end, testing-frameworks) fail because the problem was the process and team capabilities/capacity, not the tools. I think it's important to really visualise the ideal workflow for the team, and then find the tool that fits. Finding the tool first and then fitting the team to the tool is like chopping the foot to fit the shoe (which is why I'm usually wary of overly-opinionated tools).
Thank you for your share, it really helped me to choose my testing tools ! I agree with you the first thing to do is to define what the team can do ...