In the previous post, What Should I Test in the Frontend?, I focused on unit and integration testing in the frontend. In this post, I will learn about another type of frontend testing, E2E testing, and use Cypress, an E2E testing tool, to create an E2E test for my ongoing side project, and through this I will also cover how to create an E2E test.
1. Why do we need to do E2E testing?
E2E (End-to-End) testing verifies the flow of an application from start to finish, and has a different meaning from the unit testing and integration testing mentioned above. Unit testing and integration testing verify that the developed modules are working properly from the developer's perspective, but E2E testing verifies the operation of the application from the user's perspective. Therefore, E2E testing is mainly performed in a browser environment where real users use the application, and most E2E testing tools provide the ability to view the testing process in snapshots or videos.
The advantage of E2E testing is that it can be carried out in a real user environment, but at the same time, it is also a disadvantage. This makes E2E testing heavy and requires the entire application to be put into a real environment, which means that the overhead is very large. Therefore, E2E testing should only be used to verify the main usage flow of users or to verify the integration between modules, and each module should be verified to work properly with unit tests or integration tests.
However, in the frontend, UI and logic are combined, and the inverted pyramid testing (ice cream cone) anti-pattern often occurs, where many tests are created in E2E tests. Because E2E tests take a long time to run and are difficult to manage, you should create independent tests for each component using a library such as @testing-library. For information on how to create independent tests, please refer to the article What should the frontend test?
Although it has its shortcomings, E2E testing is the only type of testing that can ensure that the modules created by developers are integrated and work properly when used by users at the application level. Therefore, E2E testing is also very important.
In my opinion, there are two cases where E2E tests are very useful. The first is to ensure that the user's main path works properly from a business perspective. The second is when applying ATDD (Acceptance Test Driven Development). If some modules are not working properly, but the user's main path works properly, it may not be a critical issue from a business perspective. But if the main path does not work properly, this may become a very big problem. When writing these tests, E2E tests are very suitable
I also believe that Acquisition Test Driven Development (ATDD) is a very suitable method for teams that develop in an agile manner with iterative cycles on a user story basis. ATDD can be very attractive because it can lead to deeper discussions about the development end product among stakeholders and clearly define the development end. In fact, the reason I introduced Cypress-based E2E testing to this side project is to try applying ATDD to the next project.
Why Cypress?
Cypress is a popular E2E testing tool. Cypress is often compared to Selenium, but the main difference between these two is in their architecture: Selenium runs outside the browser and executes commands remotely over the network, while Cypress executes commands in the run loop of your application, etc. Therefore, Selenium can be written without being tied to a specific programming language, but it is slower and requires additional configuration of language-appropriate modules. On the other hand, Cypress can only be written in JavaScript, but it is faster and more integrative. Therefore, if you are developing an application with a JavaScript-based framework, you can use Cypress to quickly apply E2E testing.
2.1 Page Object Model vs. Application Working Model
As mentioned before, E2E tests are more difficult to maintain than other tests, so we often apply techniques to make this easier. In Selenium, we often use a technique called the "Page Object Model" for this. However, the Cypress community recommends using the "Application Working Model". What is the difference between the two?
Page Object Model
The page object model creates an object for the page, and defines the page's elements and actions in corresponding objects. In other words, it creates an abstraction layer above the page that encapsulates the tasks related to the page. This way, it is more flexible when changes occur; for example, if an element's ID changes, you would typically have to modify all your tests, but with the page object model you can just find the element in the Page class and modify it.
In cypress you can create a page object model like this:
