Developers, you shouldn’t do Cypress Component Testing either.
A lot of effort with low value.
A repost of my past article published on Medium in 2023.
This is a sequel to the other article, “QA Engineers, Stay Out of Cypress Component Testing, for Your Own Sake!”
I can work as a software engineer or test automation engineer. One ability that I am quite proud of is that I can put the right hat on when working on different aspects of software development work.
A short bio:
A few reputable software testing conferences listed me as the “World’s Leading Test Automation Expert”, and an author of 12 books on test automation and CT.
International Award Winning Programmer
Product Owner of several highly acclaimed software and apps I developed solo (in my spare time), such as TestWise, BuildWise, ClinicWise, SiteWise, WhenWise and TestWisely
The above is not a show-off or brag, rather, proof that I have internationally acknowledged experience in three roles: Test Automation Engineer, Software Developer, and Product Owner.
In the preceding article, “QA Engineers, Stay Out of Cypress Component Testing, for Your Own Sake!”, I expressed my perspectives concerning Cypress component testing from the standpoint of a software tester.
After all, Cypress, a black-box testing tool, claims its component testing for developers (then is it also doing white-box testing? Isn’t the naming black and white box testing just to clearly distinguish these two activities?)
In this article, I will share my thoughts on Cypress Component Testing with my developer hat on.
Table of Contents:
· My attempt at View Testing, 17 years ago.
· View Testing: Low Value
· View Testing: High Maintenance
· Cypress Component Testing: Confusing!
· Cypress Component Testing: A Sign of Failed E2E Test Automation
My attempt at View Testing, 17 years ago.
When I put “put the programmer hat” on, I understood ‘Cypress Component Testing’ quickly, it is really a kind of “unit testing a view”. Then, I realized it has little value because I tried that concept before.
About 17 years ago, I was the lead Java developer tasked with a significant challenge. I successfully undertook the endeavour of migrating a project from the notorious EJB architecture to the more favourable (at the time) Spring framework. It’s worth noting that I embarked on this mission single-handedly, as my fellow developers deemed it an insurmountable task. I succeeded, and for that effort, I was nominated for an award, which is quite usual for a contractor.
The view (in Model-View-Controller) I introduced was Apache Velocity, which was more lightweight and faster than JSP. I was a big fan of TDD (Test Driven Development) then. Besides Unit Testing and Integration Testing, I created View Testing, i.e., unit testing the view (to verify Velocity Template). I was quite excited about this before, thought it was a kind of invention. Demonstrated to the team, and received some polite ‘Cool” comments. However, it did not take long for everyone, including me, to realize it is very little value, but a big maintenance effort. We dumped it and focused on E2E Testing (as daily regression testing 👍).
View Testing: Low Value
Let me point out one apparent perspective. I knew some Cypress testers have been singing high for “Cypress Component Testing”. If it was that good and Playwright did not have it yet (Experimental), why do more and more ‘Cypress testers’ migrate to Playwright? Given this fact, the value of “Cypress Component Testing” is not that good, objectively. Don’t you agree?
I am a developer (mostly in web development), as are my daughter and many of my friends/colleagues. Why haven’t we seen the great benefits of this type of ‘Cypress Component Testing’ for over two decades? The most useful testing type, unquestionably, is End-to-End UI Testing. (End-to-end testing offers great help for developers and business analysts; check out this article)
Ironically, Cypress marketed itself as the “Selenium Killer” in the web end-to-end test automation. Except, every Cypress test automation attempt (that I witnessed) was a complete failure, with NO exceptions! Disagree? Check the facts in this article, Cypress.io is Dying.
Now Cypress introduced component testing (also, API Testing, which is another joke, see the Cypress API Testing Makes No Sense) amid failing E2E test automation everywhere, IMO, another mistake!
Above all, End-to-End (via UI) testing covers the so-called view component testing anyway. To verify a specific web page, TestWise’s Attach test execution to the existing browser can help with that.
If someone argues, “That’s not enough, we shall test all possible scenarios, including in the views”, which is “100% coverage” mentality, obviously wrong! (I have never worked on a software project with an unlimited budget and no deadline.)
View Testing: High Maintenance
A developer needs to inject data (called mount in Cypress Component Testing) to effectively unit test a view. This can be of quite some work. Of course, in the demonstration, it looks easy. In reality, a view might use page scope and session scope variables, for any data, you need to set it.
Of course, views change frequently. Moreover, the views might be modified by UI Designers. This means there will be time gaps, which may lead to undetected test failures for a while, i.e., harder to maintain.
The fact: few software engineers do View Unit Testing over the last three decades. There are, of course, very good reasons.
Cypress Component Testing: Confusing!
Testing Category: White-Box or Black-Box
Earlier, I mentioned that Cypress Component Testing is not either black-box testing or white-box testing. Maybe 80% white-box testing, but this was introduced by an end-to-end testing tool. Anyway, this article is about developers, let’s assume it belongs to white-box testing.Who is doing it? QA Engineers or Developers
I think it is a recipe for conflicts among the staff.Testing Scope
When a developer is to test a component (a view), what exactly is a component: a whole web page, a form or a single web control? According to Cypress Doc (I read that another day, but forgot the link. Correct me if I was wrong, Cypress.io is dying anyway), can be either of them.
Experienced developers would know that lacking a clearly defined scope is really bad for white-box testing. For example, a unit test or integration test is clearly created to verify a method.Execution in CI/CD
In a traditional CI process, Unit and Integration Testing are (or should be) included in the pipeline. As we know, a fair percentage of software projects failed on test execution. One common complaint or excuse is that “there is a lot mocking work with code change”. This sounds like the ‘mounting’ in Cypress component testing.
Now, adding another ‘low value, high maintenance view testing to CI, it is not hard to guess the outcome, right?
Cypress Component Testing: A Sign of Failed E2E Test Automation
For people singing for ‘Cypress Component Testing’, I point out one obvious fact: Cypress is an end-to-end testing tool.
In other words, if Cypress is used in a software project, E2E Testing must be implemented well first. OK, check yours against the Definition of End-to-End Test Automation Success. If my guess is correct, none of Cypress's implementations (you witnessed) met the criteria.
When I see a team talking about silly Cypress Component Testing but daily execution of E2E UI tests, I think of “buying an aeroplane but using it for a car”.
Another perspective from a real test automation engineer: for every run of the whole UI Test suite, he would perform the following tasks:
Analyse the test failures.
Check the requirement with Business Analysts to confirm whether it is a bug.
Update the existing test script.
Add new test scripts.
Resolve flakiness.
…
See, he will be very busy. Once a fix (in code or test script) is in (by developers or QA engineers), a repeat of all the above.
To give a feel, check out, Showcase a 500+ End-to-End (via UI) Test Suite: E2E Test Automation is Surely Feasible for Large/Complex Apps.
A green run, as the above, means each of every ~30000 test step passed!
Now, do you think you have time to do low-value, high-maintenance, and confusing Cypress component testing?! For stubborn ones, now I put on the product owner’s hat, “I don’t give a damn about this ‘cypress component testing’ (not particularly against it from a management perspective). I just want developers to code features efficiently with high-quality that satisfy end-users (good E2E UI testing helps)”.
Related Reading:
My eBooks:
- Practical Web Test Automation with Selenium WebDriver
- Practical Continuous Testing: make Agile/DevOps realBenefits of Real E2E Test Automation and Continuous Testing series: Executives, Managers, Business Analysts, Developers, Testers and Customers.