Is Cypress-the-company ok?
Every time I teach my “Cypress vs Playwright” workshop, I start by showing the students how to check the NPM releases for both tools. You can use my CLI tool available-versions to quickly see all published versions for an NPM package:
$ npx available-versions playwright
...
1.49.0 4 days latest ## Aria snapshots
1.50.0-alpha-2024-11-19 4 days
1.49.0-beta-1732008569000 3 days
1.49.0-beta-1732021985000 3 days
1.50.0-alpha-2024-11-20 3 days
1.49.0-beta-1732065049000 3 days
1.50.0-alpha-2024-11-21 2 days
1.49.0-beta-1732179895000 a day
1.49.0-beta-1732183793000 a day
1.49.0-beta-1732200847000 a day
1.49.0-beta-1732210972000 a day beta
1.50.0-alpha-2024-11-22 16 hours next
Playwright team publishes NPM versions pretty regularly, releasing a feature version like 1.48 and 1.49 every month. There are patch versions like 1.48.1, 148.2 released approximately every week.
Let’s look at Cypress releases:
13.14.2 3 months
13.15.0 2 months
13.15.1 a month
13.15.2 17 days
13.16.0 3 days
New NPM Cypress versions are published approximately every two weeks. But this is not the full story. Let’s look at the contents of each release.
Cypress v13.16.0 changelog released on November 19th only notes one “feature”: the config option defaultBrowser
. It's not a major feature, but ok.
Cypress v13.15.0 changelog released on October 25th also lists a single “feature”: “Cypress now displays more actionable errors when a Test Replay upload takes too long”. Hmm, so this feature is really only meant to make some difference when using Cypress Cloud.
So the entire month produced one smallish feature and a couple of bug fixes.
Meanwhile, the Playwright team has released several large features with each release:
version 1.49 added ARIA snapshots, test and TypeScript config features, screenshots on failures updates, canvas previews, and tracing groups.
version 1.48 added websocket mocking (!), form inputs, “Copy” network requests improvements
version 1.47 brought test runner Network tab improvements, TS filename config option, URL search params filtering for network mocking, and other small changes.
So the pace of changes in Cypress test runner itself dropped significantly compared to the active Playwright test development. This is noticeable when looking at the individual commits in https://github.com/cypress-io/cypress/commits/develop/ Most commits are dependency upgrades. The defaultBrowser
feature added in v13.16.0 was an external contribution PR #30517.
I always thought the trade-off between the commercial Cypress Cloud and the open-source test runner was fair. Companies pay for the Cloud, which allows some Cypress developers to maintain and develop the test runner. I don’t think the test runner gets much love nowadays, though. This is something to consider when you are deciding on the testing tool to use or if a migration from one tool to another makes sense.
TDD Calculator course
I often write end-to-end and component tests after the application exists. But Cypress can effectively help with test-driven development:
write a failing test first
change the application just enough to make the test pass
go to step 1
I created a new course “TDD Calculator“ with 60+ short hands-on exercises to show this in action. In each lesson, your goal is to write a failing Cypress test first, then change the application to implement the feature and make the test green. Step by step, we are developing a tiny simple HTML calculator.
Each lesson prepares the specs and the application to start coding, just check out the branch and npx cypress open
. The application is so simple, that it does not even require a static HTML server, we can directly use the cy.visit(‘public/index.html’)
command.
You will learn how to write HTML, and simple CSS, and implement the calculator functions using JavaScript. The JavaScript will become progressively more complex as we add new features: calculation history, storage, clipboard control, language translations, etc. Right now there are 60 lessons, and I am recording videos for each one. Here are the course contents:
a*
lessons show the initial calculator implementationb*
tests for individual code functionsc*
section has tests for edge cases, like invalid arithmetic expressionsd*
block saves the calculator data in thelocalStorage
e*
transition to ES6 modules to implement and test the source codef*
remove global event listeners and start using TypeScript specsg*
show how to use network and function spies and stubsh*
make the calculator work with English and German translations
I am always open to adding more lessons based on students’ questions. Want to see the calculator do something new? Ping me, and my answer might become a new bonus lesson.
Because this is Thanksgiving, feel free to use the discount code TURKEYDAY to get 25% off any of my online courses 🦃
Tip: don’t like my courses? Check out Murat Ozcan’s new Udemy course “Epic Test Arch. - test everything, everywhere all at once” that teaches comprehensive JS/TS Testing: Contract, API, UI, schema validation, Jest, Pact, Cypress, and more.
Meetups and Conferences
meetup “Writing Tests Using GitHub Copilot” at MaineJS, Portland, ME Dec 10th at 6 PM. Register at the meetup page.
conference ConFoo in Monreal Canada, Feb 26-28th, 2025. I will do a workshop plus two talks:
Workshop "Deep dive into End-to-End Testing with Cypress & Playwright", registration link, 2 days
Talk "Testing With Cypress vs Playwright: What Is the Difference?"
Talk “Writing Tests Using GitHub Copilot”
I always enjoyed the ConFoo conference, a great event with good people and lots of diverse tracks! My biggest problem is always picking which session to attend at any time slot.
If you are a meetup organizer or a conference program chair, and need an experienced speaker or workshop trainer, get in touch via https://glebbahmutov.com/#links, I am planning my 2025 year.
Code Coverage On The Fly
A fun blog post from this month: instrument the application JavaScript code using the cy.intercept
command and instrument to collect code coverage. Read “Code Coverage On The Fly“, but remember: this is probably ok for smaller projects that don’t need to bundle and minimize the source code too much.
Once instrumented, the app can be tested using normal E2E Cypress tests. The coverage report then is produced using the “standard” code coverage (CC) plugin, like my https://github.com/bahmutov/cypress-code-coverage.
End-to-end tests are extremely efficient at covering a lot of source code. The challenge is reaching all the edge cases. I recommend adding component and unit tests to fully cover hard-to-reach code, see my online course “Testing The Swag Store“ where we get 100% statement/branch coverage through a combination of E2E and React component tests. By the way, I just added new lessons to the course showing the implementation and the tests that use Vite + Cypress component tests.
Happy testing!