Developers, you shouldn't do Cypress Component Testing either. Part 1: View Unit Testing Proven little value

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 that there will be time gaps, which may lead to test failures undetected for a while, i.e. harder to maintain.

--

In the next article, I will show why Cypress Component Testing is silly for developers.