Selenium vs Cypress
Testim: Ask Me Anything
Question: Perspective on Selenium vs Cypress?
There’s a great debate in our industry in regards to comparing Selenium to Cypress. Curious how you would respond to this view: “It’s unfair to both projects, but more than anything, it emphasizes the fact that you clearly don’t understand your tooling.
They are not like for like. They are both great tools, but they are not competitors with each other. They cannot be directly compared. Then are two of the many tools available. You should be aware of them, and all the others, so you can best pick for the context you find yourself.” Wondering your thoughts on comparing these two solutions as a leader in our community?
Insights:
In simple words... Could you unscrew a screw with a thin fork? Yes. But if you have a screwdriver available, why would you? Each tool works best for a different purpose, and they are not so hard to learn. I really encourage you to try different tools and see what works best for you, disregarding of what other people say, that's the best way of learning.
-- Noemi Ferrera
Question: Are there any resources that you love for CI/CD with database changes?
Having a good amount of the right type of tests on your CI/CD is very important and if your database changes frequently, those must be there. But it's hard for me to give you a tool for everyone, as CI/CD environments differ a lot in different companies. Specifically, if you do feature toggles vs branch management. Also, not all DBs are the same, relational Vs non-relational. Some programs for databases already come with tools that could raise warnings about reversal changes. But a lot of people tend to ignore warnings. That's why you could run some schema matching tests on each CI/CD deployment front, And, as an SDET you can definitely create them too.
-- Noemi Ferrera
Question: You’ve written extensively about concurrency and parallelism and how these topics often get overlooked in testing. Can you share some of your thoughts about this issue?
I think many times the performance of people that write automation is measured by test case automated, which feeds the need to write many test cases without thinking about the usefulness or reliability of them. That leads to overlooking many false positives, such as those cause for parallel runs. Nowadays there are many tools in the market that are focused on running parallel tests to speed up the time spent in testing, which means understanding what's happening then is much more important than it used to. That's why I decided to write an article. I added concurrency because of new chips coming to the computers, I thought that could start getting more important soon, and I usually have a good intuition. It's also good to understand the difference, especially while talking to some developers that might undermine your entire knowledge if you get one thing wrong.
-- Noemi Ferrera
Last updated
