Developers, you shouldn't do Cypress Component Testing either. Part 2: Reasons to Avoid

Continue from Part 1, in which I shared my experience and opinions on View Unit Testing.

The fact: few software engineers do View Unit Testing over the last three decades. There are, of course, very good reasons.

Cypress Component Testing, as View Unit Testing from an end-to-end testing tool vendor, makes it even more silly.

Cypress Component Testing: Confusing!

1. 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.

2. Who is doing it? QA Engineers or Developers

I think it is a recipe for conflicts among the staff. 

3. 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. 

4. 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)". 

---

The original article was published on my Medium Blog, 2023-08-28

Related Reading:

• Benefits of End-to-End Test Automation for all staff involved in software development: Executives, Managers, Business Analysts, Developers, Testers (auto & manual) and Customers.