The End-to-End (E2E) Testing term is used incorrectly.
Technically, that process involves testing from the perspective of a real user.
For example, automating a scenario where a user clicks on buttons and writes text in inputs.
That's why all the components get tested in that process (from the UI to the database).
If you're using a hack, it's no longer E2E Testing, because a real user would not do that.
A common example is when you're testing a scenario that involves multiple browser tabs (e.g. SSO Login scenario).
There are some libraries out there that cannot test in multiple browser tabs (such as Cypress), so in order to automate that scenario, you would have to pass the credentials in the header or remove the target="_blank" attribute from the element that you're clicking.
That involves a hack, and that means your test no longer mimics the exact behavior of a real user.
Another one from the testing world: Accessibility Testing
Most folks think that involves checking if your elements have the title attribute (for screen readers) and if the fonts and colors are friendly for users with visual deficiencies.
But Accessibility Testing actually just means making sure that your web application works for as many users as possible.
The major mistake here is that folks forget to include cross-browser testing in this category.
So, you might have 0.01% users who need screen readers, but you actually have 20% users who are on Safari and 15% who are on Firefox and maybe even some on Internet Explorer.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The End-to-End (E2E) Testing term is used incorrectly.
Technically, that process involves testing from the perspective of a real user.
For example, automating a scenario where a user clicks on buttons and writes text in inputs.
That's why all the components get tested in that process (from the UI to the database).
If you're using a hack, it's no longer E2E Testing, because a real user would not do that.
A common example is when you're testing a scenario that involves multiple browser tabs (e.g. SSO Login scenario).
There are some libraries out there that cannot test in multiple browser tabs (such as Cypress), so in order to automate that scenario, you would have to pass the credentials in the header or remove the target="_blank" attribute from the element that you're clicking.
That involves a hack, and that means your test no longer mimics the exact behavior of a real user.
Another one from the testing world: Accessibility Testing
Most folks think that involves checking if your elements have the title attribute (for screen readers) and if the fonts and colors are friendly for users with visual deficiencies.
But Accessibility Testing actually just means making sure that your web application works for as many users as possible.
The major mistake here is that folks forget to include cross-browser testing in this category.
So, you might have 0.01% users who need screen readers, but you actually have 20% users who are on Safari and 15% who are on Firefox and maybe even some on Internet Explorer.