This is a guest post from Jeff Whelpley, CTO at Swish, Google Developer Expert, co-creator of Angular Universal (server rendering for Angular 2+), co-organizer of Boston Angular Meetup, co-organizer of Boston AI Meetup, guest/panelist on AngularAir and Adventures in Angular podcasts, and frequent speaker at local Boston meetups.
I’ve always been a big fan of really good all-in-one solutions like Angular. My general philosophy has been to rely on a small set of closely related technologies and only bring in something new if it is substantially more beneficial to the organization.
When it comes to e2e testing, most Angular projects use Protractor because it was built for Angular and it’s baked directly into the Angular CLI. Oh, and it’s legit. There is no doubt that Protractor works really well for most Angular projects.
Despite all of that, my team at Swish just recently voted unanimously to start using Cypress across the board for all e2e testing on our Angular projects.
At a high level, the primary reason for this switch was because over the course of 2 months, our developers wrote more e2e tests and got more value out of Cypress than the previous 2 years combined with Protractor. That is not to say that Protractor is a bad testing framework. It’s not. It’s just that Cypress has proved to be much better for our team and our product.
There are three primary reasons why Cypress has become a universally loved and indispensable tool for us:
- The API
- Stability
- Tooling
The rest of this article will get into the details for each of these areas.
The API
The entire Cypress API hangs off one global object, cy. Protractor, on the other hand, has a number of top level objects such as browser, element, by and utils. This may seem like a trivial difference, but this one little thing has proven to have a big impact the number of tests we write and how fast we write each test.
It took us a bit of reflection to understand this, but when you use the same global object for basically everything, you never have to remind yourself about how to test something. It is always the same. Just start typing cy and then let the great autocomplete documentation guide you.
Again, I understand this may seem like a small, trivial matter, but it has made all the difference in the world for us. The friction that exists with the Protractor API is not that much worse than Cypress, but almost any small amount of friction will push a developer toward the mindset “I don’t have time to write a test now, but I will do it later” (and then it never gets done).
Stability
While the awesome Cypress API gets us to actually write the tests in the first place, the amazingly consistent stability of Cypress ensures we actually maintain the tests over time.
N-O-T-H-I-N-G…seriously, nothing is more frustrating in the testing world than flaky tests that pass one minute and then fail the next. No doubt Protractor has improved in this area, but it’s still built on top of Selenium so there is only so much they can do.
I don’t think a developer can truly appreciate the stability of Cypres until they’ve spent endless hours tracking down the source of a failing e2e test only to find nothing. Then reboot your computer or something else stupid like that and the test starts passing again.
Arrrrghhhhhh!!!!
Thank you, Cypress. I love you.
Tooling
So, this is where I really start to get excited. There’s a lot to talk about for Cypress tooling, but I can boil it all down to the one most important thing:
When a test breaks, Cypress makes it insanely easy to figure out what went wrong and fix the issue.
There are three features that come together to create this awesome experience:
- Time Travel - Cypress takes snapshots of your app as the tests run. The UI makes it really clear where a failure occurred and you can see exactly what the UI looked like at that moment (as well as how it looked leading up to that error).
- Clear Error Messages - Someone at Cypress spent a lot of time making sure error messages are accurate, useful and (most important) actionable.
- Speed - I don’t have stats to prove this, but the Cypress test runner has always just felt faster to me. This is especially important when you are trying to fix a broken test and need the quick feedback loop to see whether your fix worked.
Final Thought
I would never claim that Cypress is the perfect fit for every development team out there. However, I do feel very strongly that every Angular developer should try it out for themselves and make their own decision. I am fairly confident that if you give Cypress a chance, it won’t be long before you join me in the ranks of Protractor-to-Cypress converts.