QA Engineers, Stay Out of Cypress Component Testing, for Your Own Sake!

I have been hearing Cypress testers, who are unable to do end-to-end testing, started talking about how great Cypress Component Testing is.

Cypress Component Testing, let’s just accept the term that Cypress defines, is mainly for developers.

“Cypress currently has official mounting libraries for React, Angular, Vue, and Svelte and support for the following development servers and frameworks: Create React App 4+, Next.js 11+, …” — Cypress Doc

Clearly, Cypress Component Testing is NOT black-box testing (as an end-user), as it is limited to the apps in a certain web framework (even specific versions). At most, it is ‘Gray-box testing’. I have seen some examples on its official doc, frankly, it is quite complex and messy (You can verify the example script with your end-user or manual tester).

There is a "mount" task (to include the component code) before testing. Here is an official example:

I know the argument for Cypress component testing, “browser-based, allowing you test not only your component’s functionality but also styles and appearance” [doc]. From my 20+ years of experience (in both coding and testing), this has very little value, which I will elaborate in a separate article. For Cypress testers fixated on this, (by the way, Cypress.IO is dying) just think the following simple questions:

• Why it is NOT included in Testing Pyramid?
• Did your team do end-to-end UI Testing (in the Testing Pyramid) well?
• Every activity comes with a cost. Do you, from the project’s perspective, really think the effort on this kind of component testing is justifiable?

Black and White

By the way, we call “BlackBox” and “WhiteBox” testing for a very good reason, indicating there is a clear gap, no middle ground. But the so-called cypress component testing (if performed by QA engineers) crosses that line.

I might be an old-fashion software engineer and SET. I think mixing black-box and white-box testing is wrong, very wrong.

Frankly, as an experienced developer and test automation engineer, I think Cypress component testing is of no use at all, which will be covered in another article.

Here, I will talk about why it will cause problems (for QA Engineers) when used in a real software project, from a practical perspective. Developers using this for Shift-Left Testing is out of the discussion in this article. I will just discuss the troubles when QA engineers started doing this kind of so-called component testing.

Let’s get some facts out first.

• Software Developers have high egos.

Talking about “high egos”, can you think of another profession?

• Generally speaking, Developers look down on testers.

Accept this fact. I have been working as a senior developer and test automation engineer, for 10+ years each. I know that well. In the first episode of the classic “Silicon Valley” show, two programmers mocked Richard, a QA Engineer who developed a website. A good scene!

Moreover, if there is a conflict between a developer and a QA engineer, the manager almost certainly supports the developer.

• QA Engineers’ job is to verify developers’ work

Raising a defect, in plain words, is telling all team members “This developer’s code is no good”.

• Most developers do not write unit tests or integration tests well

In other words, they lack an understanding of test automation or sympathy for your work. They are quite sensitive to people getting to know their testing practices, because of a common saying, “Good programmers do TDD or write good unit tests”.

Wise readers will get my points already.

Let me share a story. In 2005, I was the technical lead of the team, and we used jWebUnit as the automation framework to verify user stories. One tester is assigned to work with one developer. There were so many human issues, and the perfect planning by management and myself did not work out. That was even end-to-end testing but without UI. We did have a trial, the test lead and me as a pair, which worked quite well. But we forgot the human factors! I remember one conflict between the developer and the tester almost getting physical.

Now, hypothetically, a QA engineer reports a few defects against one developer, based on its latest Cypress Component Testing results. This developer happened to be quite stressed (common for developers) and in a bad mood (not uncommon). The developer might criticise the QA Engineer with the following harsh words:

1. “OK, Did you test the user story end-to-end?” (this is a friendly developer. Most likely, Cypress testers failed to do end-to-end testing)
2. “I think this is not useful at all. No offence, the UI will continue to change, might even one month after the first production release. You will be spending too much time maintaining these very low-value tests. The core UI will be covered by your end-to-end testing, right?” (another quite friendly developer)
3. “You used the wrong code to mount. Don’t you understand Git?”
4. “You should not test the component at this level!”
5. “You should use TypeScript, it is good”, or “You must NOT use TypeScript, it is bad”!
6. “The JavaScript you wrote is poor, you shouldn’t do this way. Maybe you should re-learn JavaScript.”
7. “I modified your component testing scripts, I cannot tolerate bad code.” (then you don’t understand your test scripts now).
8. “Stop asking me questions about the view code (to mount), I am busy!”
9. “You are hired to do end-to-end testing, which we desperately need. Why you are doing this? If you can’t do what are hired for, what makes you think can do this component testing?”
10. “Your so-called component testing is clearly wrong. You injected the wrong data, and of course, the view behaviour is different from you what expect”.
11. “Don’t waste time on testing the look and feel (UI) of the page yet, at least not this level. Our graphic designers will redo the UI towards the end. Can you focus on testing the functionality, end-to-end functional testing, which really matters?”
12. “I heard Cypress.io company is dying, why you are still using it here?”
13. “We haven’t seen any useful end-to-end testing from your guys for months. We rely on manual testers. Manager, please don’t let this guy bother us. It is better for them to keep faking there”.
14. …

If you don’t listen to the wise saying “QA engineers stay on black box testing”, you might get this.

Probably would learn a lesson then.

So QA engineers, don’t muck around. If you don’t know end-to-end (UI) test automation (very common, it is the fault of IT education), acknowledge and then learn it. For most Cypress testers, don’t forget, “You were hired to perform end-to-end (via UI) testing anyway”.

---

Related reading:

My eBooks:

• Practical Web Test Automation with Selenium WebDriver
• Selenium WebDriver Recipes in Ruby
• Practical Continuous Testing: make Agile/DevOps real