What are component tests?<\/strong><\/h2>\n\n\n\nComponent tests in front-end testing involve checking individual components or units of a web application in isolation. The main goal is to ensure that each component works as expected at an early stage of development.<\/p>\n\n\n\n
Components are usually smaller, independent user interface parts, such as:<\/p>\n\n\n\n
\n- buttons,<\/li>\n\n\n\n
- forms,<\/li>\n\n\n\n
- or custom UI elements.<\/li>\n<\/ul>\n\n\n\n
For example, a popular \u201cdate-picker\u201d fits perfectly into this definition and is an excellent subject for testing on your own keyboard.<\/p>\n\n\n\n
Benefits of component tests<\/strong><\/h3>\n\n\n\nThese tests bring several benefits, including:<\/p>\n\n\n\n
\n- Isolation testing \u2013 <\/strong>this means we don’t need actual working software, service, website, or server to conduct the test. It saves time and increases test stability.<\/li>\n\n\n\n
- Small and fast tests \u2013 <\/strong>we conduct component tests almost like unit tests. This lets us detect irregularities quickly, resulting in quick and relatively inexpensive fixes.<\/li>\n\n\n\n
- Easy and readable code <\/strong>\u2013 using this practice, we introduce ease of code maintenance and increase its clarity. The application is divided into smaller parts, which are then tested by these component tests.<\/li>\n\n\n\n
- Automation and integration \u2013 <\/strong>these tests can be easily automated and integrated into continuous integration tools. We can also run them locally on a Docker container, particularly useful when starting the journey with automated tests.<\/li>\n<\/ul>\n\n\n\n
But why do we need component tests?<\/strong><\/h2>\n\n\n\nTo answer this question, we need to understand the necessity and essence of automated tests. An automated test is part of the process of checking test scenarios using automation tools or scripts. However, it’s important to remember the testing basics, as they are crucial when creating test cases. In my opinion, a good automated test should consist of three elements:<\/p>\n\n\n\n
\n- Test data,<\/li>\n\n\n\n
- Steps,<\/li>\n\n\n\n
- One assertion.<\/li>\n<\/ol>\n\n\n\n
I touch on a rather controversial topic<\/strong> by emphasizing the last point as a critical criterion. In my view, a test that checks many things is unreliable, difficult to maintain, and complicated to verify.<\/p>\n\n\n\nLet’s consider a situation<\/strong> where we want to write a test that submits a user registration form. We fill in all the fields and click the “submit” button using cy.contains(“submit”). However, a question arises \u2013 what happens if our button has different text, for instance, due to issues displaying special characters? We get a negative result in a test that creates a user even though the string (commonly known as a “string”) we are searching for is different.<\/p>\n\n\n\nWhat can we do in this situation? We should write a better test<\/strong>! We can use the cy.get() method and provide our unique identifier (cy-data locator) here. This method eliminates the need to search for elements by a specific string and instead refers to the locator. However, we sometimes use the cy.contains() method because it is more convenient and effective than cy.get().<\/p>\n\n\n\nBut what if we had a component test that generates this element with the expected string, simultaneously checking its text, behavior, and CSS styles? Our continuous integration tool would only allow further tests to run if we fixed what produced a negative result. Thanks to early error detection, we can quickly and cheaply fix it. Additionally, this prevents false negatives in other tests where the component is at fault, not the logic of the code itself.<\/p>\n\n\n\n
Component testing vs. the Testing Pyramid<\/strong><\/strong><\/h2>\n\n\n\nThe Testing Pyramid is a “design pattern” that outlines the hierarchy and quantity of tests. According to generally accepted standards, it is divided into three levels, stacked one on top of the other, in order of creation\/maintenance cost or execution time.<\/p>\n\n\n\n![\"The](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image1-3.png\")
<\/a>Fig. 1 The Testing Pyramid depicts the three main levels of tests<\/figcaption><\/figure>\n\n\n\nUnit test<\/strong>s<\/h3>\n\n\n\nDevelopers usually write these and aim to verify a method\/function\/module at a unit level. They should have the highest, realistic code coverage. Unit tests are represented as the foundation of the testing pyramid because:<\/p>\n\n\n\n
\n- They are independent of external services.<\/li>\n\n\n\n
- They are extremely quick to write and execute.<\/li>\n\n\n\n
- They are inexpensive to maintain and create.<\/li>\n<\/ul>\n\n\n\n
They can also serve as a form of project documentation.<\/p>\n\n\n\n
Integration tests<\/strong><\/h3>\n\n\n\nAt the next level are integration tests, which include system, functional, and integration tests. These tests verify whether individual modules communicate with each other using both test and real data. These tests are primarily written and executed by testers, but this also depends on team agreements and project approach. Depending on complexity, they may rely on external services but are certainly cheaper and faster than end-to-end tests (E2E).<\/p>\n\n\n\n
End-to-end tests<\/strong><\/h3>\n\n\n\nThese tests verify business paths from user creation to purchasing items in an online store. However, they have the following disadvantages:<\/p>\n\n\n\n
\n- They are unstable.<\/li>\n\n\n\n
- They are costly to create and maintain.<\/li>\n\n\n\n
- They cover a minimal portion of code.<\/li>\n\n\n\n
- Their execution time is much longer compared to unit or integration tests.<\/li>\n<\/ul>\n\n\n\n
Where do component tests fit into the testing pyramid?<\/strong><\/h3>\n\n\n\nBased on what we’ve read about both component tests and the Testing Pyramid, they sit between the unit and integration layers. This is precisely where I place them.<\/p>\n\n\n\n![\"Testing](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image2-1.png\")
<\/a>Fig. 2 Testing Pyramid with placement of component tests<\/figcaption><\/figure>\n\n\n\nWho should write\/create component tests?<\/strong><\/h2>\n\n\n\nHere, we encounter a situation similar to that of unit tests. Internet sources claim that developers are responsible for component tests. However, I know from experience that most developers focus more on code implementation than writing tests. This is also a debatable topic related to the definition of done, project approach, and team dynamics.<\/p>\n\n\n\n
In my opinion, writing component tests is an ideal task for a tester who wants to start their journey with automated testing. These tests are easy to write and maintain, and their results are clear, reliable, and transparent.<\/p>\n\n\n\n
Component tests in practice<\/strong><\/h2>\n\n\n\nHere, I will discuss two approaches: the old and the new way of creating component tests using JavaScript with Cypress.<\/p>\n\n\n\n
Old-fashion way<\/strong><\/h3>\n\n\n\nThis approach is encountered in Cypress and other testing frameworks where we cannot currently display components. Knowing these limitations, let’s proceed with implementation.<\/p>\n\n\n\n
We want our test to verify if our website’s “Click me” button meets our expectations. We need to check the button on our locally running software version at http:\/\/localhost:4200\/<\/a>.<\/p>\n\n\n\n![\"Verification](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image3-2.png\")
<\/a>Fig. 3 Verification of the operation of the \u201cClick me\u201d button<\/figcaption><\/figure>\n\n\n\nWe create test cases and check if it works.<\/p>\n\n\n\n
\n- Check if the button has the label “Click me.”<\/li>\n\n\n\n
- Verify if the button has a red background color.<\/li>\n\n\n\n
- Ensure the button correctly displays the text “1!2#45.”<\/li>\n\n\n\n
- Confirm if the button displays the color changed to blue correctly.<\/li>\n<\/ol>\n\n\n\n
![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image4-1.png\")
<\/a><\/figure>\n\n\n\nThe presented code looks neat and readable. Using the Page-Object design pattern and pulling recurring elements into variables can make it even clearer. Its drawback is undoubtedly the execution time, which, with four tests, is only 809 ms or as much as 809 ms.<\/p>\n\n\n\n
Here, we need to note that we access the button immediately after loading “localhost.” It does not require any additional interaction, allowing us to achieve an acceptable time for four test cases. However, it becomes more complicated to extract individual elements, for example, from the third page of the user edit form to reach the reset button, which only appears after editing any field.<\/p>\n\n\n\n
Suddenly, your test looks like this:<\/p>\n\n\n\n![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image5-3.png\")
<\/a><\/figure>\n\n\n\nAcquiring this element can take a lot of time, leading to a significant increase in code and dependence on other services. What if we were to test the button on the “production” server? It took me 12 seconds to execute these four tests.<\/p>\n\n\n\n
What can we do to make our test better and faster?<\/strong><\/h2>\n\n\n\n\n- If we have Storybook or similar tools, let’s write tests there. We may encounter inconveniences with iframes, but the scale of these inconveniences is drastically smaller compared to the time it takes to run these tests, and they are very close to component tests themselves.<\/li>\n\n\n\n
- Combine all assertions into one test using so-called “Soft assertions” (an assertion that does not immediately fail the test upon occurrence) to save time when visiting the page or element. This idea can be beneficial, especially with the right reporter, which can really pay off. (This is a potential anti-pattern because a test should ideally consist of a single assertion, but… that’s a topic for another post). I managed to achieve a time of 358 ms.<\/li>\n\n\n\n
- Do not refresh the page and perform assertions in separate tests (anti-pattern because tests depend on each other) \u2013 time: 278 ms.<\/li>\n\n\n\n
- Use the cy.mount() method to utilize Cypress’s component testing!<\/li>\n<\/ol>\n\n\n\n
![\"code\"](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image6-2.png\")
<\/a><\/figure>\n\n\n\nWith this method, we can generate the component individually by importing it and passing it to the mount() method. It saves time on writing and execution, keeps the code clear, and ensures reliable tests. The time I achieved was 162 ms! This is the best result so far.<\/p>\n\n\n\n![\"Component](\"https:\/\/sii.pl\/blog\/wp-content\/uploads\/2024\/06\/image7-3-1024x244.png\")
<\/a>Fig. 4 Component testing<\/figcaption><\/figure>\n\n\n\nIf not Cypress, then what?<\/strong><\/h2>\n\n\n\nComponent testing is not limited to Cypress alone. There are several alternative tools, such as<\/p>\n\n\n\n
\n- Jest,<\/li>\n\n\n\n
- Enzyme,<\/li>\n\n\n\n
- Vue Test Utils,<\/li>\n<\/ul>\n\n\n\n
which can also be effectively used for this practice.<\/p>\n\n\n\n
These diverse options allow developers to tailor tools to specific project needs, which becomes particularly important in situations where Cypress, for various reasons, does not meet expectations.<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Learn more about Cypress in other articles by our experts<\/a>.<\/p>\n\n\n
For example, a popular \u201cdate-picker\u201d fits perfectly into this definition and is an excellent subject for testing on your own keyboard.<\/p>\n\n\n\n
Benefits of component tests<\/strong><\/h3>\n\n\n\nThese tests bring several benefits, including:<\/p>\n\n\n\n
\n- Isolation testing \u2013 <\/strong>this means we don’t need actual working software, service, website, or server to conduct the test. It saves time and increases test stability.<\/li>\n\n\n\n
- Small and fast tests \u2013 <\/strong>we conduct component tests almost like unit tests. This lets us detect irregularities quickly, resulting in quick and relatively inexpensive fixes.<\/li>\n\n\n\n
- Easy and readable code <\/strong>\u2013 using this practice, we introduce ease of code maintenance and increase its clarity. The application is divided into smaller parts, which are then tested by these component tests.<\/li>\n\n\n\n
- Automation and integration \u2013 <\/strong>these tests can be easily automated and integrated into continuous integration tools. We can also run them locally on a Docker container, particularly useful when starting the journey with automated tests.<\/li>\n<\/ul>\n\n\n\n
But why do we need component tests?<\/strong><\/h2>\n\n\n\nTo answer this question, we need to understand the necessity and essence of automated tests. An automated test is part of the process of checking test scenarios using automation tools or scripts. However, it’s important to remember the testing basics, as they are crucial when creating test cases. In my opinion, a good automated test should consist of three elements:<\/p>\n\n\n\n
\n- Test data,<\/li>\n\n\n\n
- Steps,<\/li>\n\n\n\n
- One assertion.<\/li>\n<\/ol>\n\n\n\n
I touch on a rather controversial topic<\/strong> by emphasizing the last point as a critical criterion. In my view, a test that checks many things is unreliable, difficult to maintain, and complicated to verify.<\/p>\n\n\n\nLet’s consider a situation<\/strong> where we want to write a test that submits a user registration form. We fill in all the fields and click the “submit” button using cy.contains(“submit”). However, a question arises \u2013 what happens if our button has different text, for instance, due to issues displaying special characters? We get a negative result in a test that creates a user even though the string (commonly known as a “string”) we are searching for is different.<\/p>\n\n\n\nWhat can we do in this situation? We should write a better test<\/strong>! We can use the cy.get() method and provide our unique identifier (cy-data locator) here. This method eliminates the need to search for elements by a specific string and instead refers to the locator. However, we sometimes use the cy.contains() method because it is more convenient and effective than cy.get().<\/p>\n\n\n\nBut what if we had a component test that generates this element with the expected string, simultaneously checking its text, behavior, and CSS styles? Our continuous integration tool would only allow further tests to run if we fixed what produced a negative result. Thanks to early error detection, we can quickly and cheaply fix it. Additionally, this prevents false negatives in other tests where the component is at fault, not the logic of the code itself.<\/p>\n\n\n\n
Component testing vs. the Testing Pyramid<\/strong><\/strong><\/h2>\n\n\n\nThe Testing Pyramid is a “design pattern” that outlines the hierarchy and quantity of tests. According to generally accepted standards, it is divided into three levels, stacked one on top of the other, in order of creation\/maintenance cost or execution time.<\/p>\n\n\n\n<\/a>Fig. 1 The Testing Pyramid depicts the three main levels of tests<\/figcaption><\/figure>\n\n\n\nUnit test<\/strong>s<\/h3>\n\n\n\nDevelopers usually write these and aim to verify a method\/function\/module at a unit level. They should have the highest, realistic code coverage. Unit tests are represented as the foundation of the testing pyramid because:<\/p>\n\n\n\n
\n- They are independent of external services.<\/li>\n\n\n\n
- They are extremely quick to write and execute.<\/li>\n\n\n\n
- They are inexpensive to maintain and create.<\/li>\n<\/ul>\n\n\n\n
They can also serve as a form of project documentation.<\/p>\n\n\n\n
Integration tests<\/strong><\/h3>\n\n\n\nAt the next level are integration tests, which include system, functional, and integration tests. These tests verify whether individual modules communicate with each other using both test and real data. These tests are primarily written and executed by testers, but this also depends on team agreements and project approach. Depending on complexity, they may rely on external services but are certainly cheaper and faster than end-to-end tests (E2E).<\/p>\n\n\n\n
End-to-end tests<\/strong><\/h3>\n\n\n\nThese tests verify business paths from user creation to purchasing items in an online store. However, they have the following disadvantages:<\/p>\n\n\n\n
\n- They are unstable.<\/li>\n\n\n\n
- They are costly to create and maintain.<\/li>\n\n\n\n
- They cover a minimal portion of code.<\/li>\n\n\n\n
- Their execution time is much longer compared to unit or integration tests.<\/li>\n<\/ul>\n\n\n\n
Where do component tests fit into the testing pyramid?<\/strong><\/h3>\n\n\n\nBased on what we’ve read about both component tests and the Testing Pyramid, they sit between the unit and integration layers. This is precisely where I place them.<\/p>\n\n\n\n<\/a>Fig. 2 Testing Pyramid with placement of component tests<\/figcaption><\/figure>\n\n\n\nWho should write\/create component tests?<\/strong><\/h2>\n\n\n\nHere, we encounter a situation similar to that of unit tests. Internet sources claim that developers are responsible for component tests. However, I know from experience that most developers focus more on code implementation than writing tests. This is also a debatable topic related to the definition of done, project approach, and team dynamics.<\/p>\n\n\n\n
In my opinion, writing component tests is an ideal task for a tester who wants to start their journey with automated testing. These tests are easy to write and maintain, and their results are clear, reliable, and transparent.<\/p>\n\n\n\n
Component tests in practice<\/strong><\/h2>\n\n\n\nHere, I will discuss two approaches: the old and the new way of creating component tests using JavaScript with Cypress.<\/p>\n\n\n\n
Old-fashion way<\/strong><\/h3>\n\n\n\nThis approach is encountered in Cypress and other testing frameworks where we cannot currently display components. Knowing these limitations, let’s proceed with implementation.<\/p>\n\n\n\n
We want our test to verify if our website’s “Click me” button meets our expectations. We need to check the button on our locally running software version at http:\/\/localhost:4200\/<\/a>.<\/p>\n\n\n\n<\/a>Fig. 3 Verification of the operation of the \u201cClick me\u201d button<\/figcaption><\/figure>\n\n\n\nWe create test cases and check if it works.<\/p>\n\n\n\n
\n- Check if the button has the label “Click me.”<\/li>\n\n\n\n
- Verify if the button has a red background color.<\/li>\n\n\n\n
- Ensure the button correctly displays the text “1!2#45.”<\/li>\n\n\n\n
- Confirm if the button displays the color changed to blue correctly.<\/li>\n<\/ol>\n\n\n\n
<\/a><\/figure>\n\n\n\nThe presented code looks neat and readable. Using the Page-Object design pattern and pulling recurring elements into variables can make it even clearer. Its drawback is undoubtedly the execution time, which, with four tests, is only 809 ms or as much as 809 ms.<\/p>\n\n\n\n
Here, we need to note that we access the button immediately after loading “localhost.” It does not require any additional interaction, allowing us to achieve an acceptable time for four test cases. However, it becomes more complicated to extract individual elements, for example, from the third page of the user edit form to reach the reset button, which only appears after editing any field.<\/p>\n\n\n\n
Suddenly, your test looks like this:<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nAcquiring this element can take a lot of time, leading to a significant increase in code and dependence on other services. What if we were to test the button on the “production” server? It took me 12 seconds to execute these four tests.<\/p>\n\n\n\n
What can we do to make our test better and faster?<\/strong><\/h2>\n\n\n\n\n- If we have Storybook or similar tools, let’s write tests there. We may encounter inconveniences with iframes, but the scale of these inconveniences is drastically smaller compared to the time it takes to run these tests, and they are very close to component tests themselves.<\/li>\n\n\n\n
- Combine all assertions into one test using so-called “Soft assertions” (an assertion that does not immediately fail the test upon occurrence) to save time when visiting the page or element. This idea can be beneficial, especially with the right reporter, which can really pay off. (This is a potential anti-pattern because a test should ideally consist of a single assertion, but… that’s a topic for another post). I managed to achieve a time of 358 ms.<\/li>\n\n\n\n
- Do not refresh the page and perform assertions in separate tests (anti-pattern because tests depend on each other) \u2013 time: 278 ms.<\/li>\n\n\n\n
- Use the cy.mount() method to utilize Cypress’s component testing!<\/li>\n<\/ol>\n\n\n\n
<\/a><\/figure>\n\n\n\nWith this method, we can generate the component individually by importing it and passing it to the mount() method. It saves time on writing and execution, keeps the code clear, and ensures reliable tests. The time I achieved was 162 ms! This is the best result so far.<\/p>\n\n\n\n<\/a>Fig. 4 Component testing<\/figcaption><\/figure>\n\n\n\nIf not Cypress, then what?<\/strong><\/h2>\n\n\n\nComponent testing is not limited to Cypress alone. There are several alternative tools, such as<\/p>\n\n\n\n
\n- Jest,<\/li>\n\n\n\n
- Enzyme,<\/li>\n\n\n\n
- Vue Test Utils,<\/li>\n<\/ul>\n\n\n\n
which can also be effectively used for this practice.<\/p>\n\n\n\n
These diverse options allow developers to tailor tools to specific project needs, which becomes particularly important in situations where Cypress, for various reasons, does not meet expectations.<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Learn more about Cypress in other articles by our experts<\/a>.<\/p>\n\n\n
But why do we need component tests?<\/strong><\/h2>\n\n\n\nTo answer this question, we need to understand the necessity and essence of automated tests. An automated test is part of the process of checking test scenarios using automation tools or scripts. However, it’s important to remember the testing basics, as they are crucial when creating test cases. In my opinion, a good automated test should consist of three elements:<\/p>\n\n\n\n
\n- Test data,<\/li>\n\n\n\n
- Steps,<\/li>\n\n\n\n
- One assertion.<\/li>\n<\/ol>\n\n\n\n
I touch on a rather controversial topic<\/strong> by emphasizing the last point as a critical criterion. In my view, a test that checks many things is unreliable, difficult to maintain, and complicated to verify.<\/p>\n\n\n\nLet’s consider a situation<\/strong> where we want to write a test that submits a user registration form. We fill in all the fields and click the “submit” button using cy.contains(“submit”). However, a question arises \u2013 what happens if our button has different text, for instance, due to issues displaying special characters? We get a negative result in a test that creates a user even though the string (commonly known as a “string”) we are searching for is different.<\/p>\n\n\n\nWhat can we do in this situation? We should write a better test<\/strong>! We can use the cy.get() method and provide our unique identifier (cy-data locator) here. This method eliminates the need to search for elements by a specific string and instead refers to the locator. However, we sometimes use the cy.contains() method because it is more convenient and effective than cy.get().<\/p>\n\n\n\nBut what if we had a component test that generates this element with the expected string, simultaneously checking its text, behavior, and CSS styles? Our continuous integration tool would only allow further tests to run if we fixed what produced a negative result. Thanks to early error detection, we can quickly and cheaply fix it. Additionally, this prevents false negatives in other tests where the component is at fault, not the logic of the code itself.<\/p>\n\n\n\n
Component testing vs. the Testing Pyramid<\/strong><\/strong><\/h2>\n\n\n\nThe Testing Pyramid is a “design pattern” that outlines the hierarchy and quantity of tests. According to generally accepted standards, it is divided into three levels, stacked one on top of the other, in order of creation\/maintenance cost or execution time.<\/p>\n\n\n\n<\/a>Fig. 1 The Testing Pyramid depicts the three main levels of tests<\/figcaption><\/figure>\n\n\n\nUnit test<\/strong>s<\/h3>\n\n\n\nDevelopers usually write these and aim to verify a method\/function\/module at a unit level. They should have the highest, realistic code coverage. Unit tests are represented as the foundation of the testing pyramid because:<\/p>\n\n\n\n
\n- They are independent of external services.<\/li>\n\n\n\n
- They are extremely quick to write and execute.<\/li>\n\n\n\n
- They are inexpensive to maintain and create.<\/li>\n<\/ul>\n\n\n\n
They can also serve as a form of project documentation.<\/p>\n\n\n\n
Integration tests<\/strong><\/h3>\n\n\n\nAt the next level are integration tests, which include system, functional, and integration tests. These tests verify whether individual modules communicate with each other using both test and real data. These tests are primarily written and executed by testers, but this also depends on team agreements and project approach. Depending on complexity, they may rely on external services but are certainly cheaper and faster than end-to-end tests (E2E).<\/p>\n\n\n\n
End-to-end tests<\/strong><\/h3>\n\n\n\nThese tests verify business paths from user creation to purchasing items in an online store. However, they have the following disadvantages:<\/p>\n\n\n\n
\n- They are unstable.<\/li>\n\n\n\n
- They are costly to create and maintain.<\/li>\n\n\n\n
- They cover a minimal portion of code.<\/li>\n\n\n\n
- Their execution time is much longer compared to unit or integration tests.<\/li>\n<\/ul>\n\n\n\n
Where do component tests fit into the testing pyramid?<\/strong><\/h3>\n\n\n\nBased on what we’ve read about both component tests and the Testing Pyramid, they sit between the unit and integration layers. This is precisely where I place them.<\/p>\n\n\n\n<\/a>Fig. 2 Testing Pyramid with placement of component tests<\/figcaption><\/figure>\n\n\n\nWho should write\/create component tests?<\/strong><\/h2>\n\n\n\nHere, we encounter a situation similar to that of unit tests. Internet sources claim that developers are responsible for component tests. However, I know from experience that most developers focus more on code implementation than writing tests. This is also a debatable topic related to the definition of done, project approach, and team dynamics.<\/p>\n\n\n\n
In my opinion, writing component tests is an ideal task for a tester who wants to start their journey with automated testing. These tests are easy to write and maintain, and their results are clear, reliable, and transparent.<\/p>\n\n\n\n
Component tests in practice<\/strong><\/h2>\n\n\n\nHere, I will discuss two approaches: the old and the new way of creating component tests using JavaScript with Cypress.<\/p>\n\n\n\n
Old-fashion way<\/strong><\/h3>\n\n\n\nThis approach is encountered in Cypress and other testing frameworks where we cannot currently display components. Knowing these limitations, let’s proceed with implementation.<\/p>\n\n\n\n
We want our test to verify if our website’s “Click me” button meets our expectations. We need to check the button on our locally running software version at http:\/\/localhost:4200\/<\/a>.<\/p>\n\n\n\n<\/a>Fig. 3 Verification of the operation of the \u201cClick me\u201d button<\/figcaption><\/figure>\n\n\n\nWe create test cases and check if it works.<\/p>\n\n\n\n
\n- Check if the button has the label “Click me.”<\/li>\n\n\n\n
- Verify if the button has a red background color.<\/li>\n\n\n\n
- Ensure the button correctly displays the text “1!2#45.”<\/li>\n\n\n\n
- Confirm if the button displays the color changed to blue correctly.<\/li>\n<\/ol>\n\n\n\n
<\/a><\/figure>\n\n\n\nThe presented code looks neat and readable. Using the Page-Object design pattern and pulling recurring elements into variables can make it even clearer. Its drawback is undoubtedly the execution time, which, with four tests, is only 809 ms or as much as 809 ms.<\/p>\n\n\n\n
Here, we need to note that we access the button immediately after loading “localhost.” It does not require any additional interaction, allowing us to achieve an acceptable time for four test cases. However, it becomes more complicated to extract individual elements, for example, from the third page of the user edit form to reach the reset button, which only appears after editing any field.<\/p>\n\n\n\n
Suddenly, your test looks like this:<\/p>\n\n\n\n<\/a><\/figure>\n\n\n\nAcquiring this element can take a lot of time, leading to a significant increase in code and dependence on other services. What if we were to test the button on the “production” server? It took me 12 seconds to execute these four tests.<\/p>\n\n\n\n
What can we do to make our test better and faster?<\/strong><\/h2>\n\n\n\n\n- If we have Storybook or similar tools, let’s write tests there. We may encounter inconveniences with iframes, but the scale of these inconveniences is drastically smaller compared to the time it takes to run these tests, and they are very close to component tests themselves.<\/li>\n\n\n\n
- Combine all assertions into one test using so-called “Soft assertions” (an assertion that does not immediately fail the test upon occurrence) to save time when visiting the page or element. This idea can be beneficial, especially with the right reporter, which can really pay off. (This is a potential anti-pattern because a test should ideally consist of a single assertion, but… that’s a topic for another post). I managed to achieve a time of 358 ms.<\/li>\n\n\n\n
- Do not refresh the page and perform assertions in separate tests (anti-pattern because tests depend on each other) \u2013 time: 278 ms.<\/li>\n\n\n\n
- Use the cy.mount() method to utilize Cypress’s component testing!<\/li>\n<\/ol>\n\n\n\n
<\/a><\/figure>\n\n\n\nWith this method, we can generate the component individually by importing it and passing it to the mount() method. It saves time on writing and execution, keeps the code clear, and ensures reliable tests. The time I achieved was 162 ms! This is the best result so far.<\/p>\n\n\n\n<\/a>Fig. 4 Component testing<\/figcaption><\/figure>\n\n\n\nIf not Cypress, then what?<\/strong><\/h2>\n\n\n\nComponent testing is not limited to Cypress alone. There are several alternative tools, such as<\/p>\n\n\n\n
\n- Jest,<\/li>\n\n\n\n
- Enzyme,<\/li>\n\n\n\n
- Vue Test Utils,<\/li>\n<\/ul>\n\n\n\n
which can also be effectively used for this practice.<\/p>\n\n\n\n
These diverse options allow developers to tailor tools to specific project needs, which becomes particularly important in situations where Cypress, for various reasons, does not meet expectations.<\/p>\n\n\n\n
***<\/p>\n\n\n\n
Learn more about Cypress in other articles by our experts<\/a>.<\/p>\n\n\n
I touch on a rather controversial topic<\/strong> by emphasizing the last point as a critical criterion. In my view, a test that checks many things is unreliable, difficult to maintain, and complicated to verify.<\/p>\n\n\n\n Let’s consider a situation<\/strong> where we want to write a test that submits a user registration form. We fill in all the fields and click the “submit” button using cy.contains(“submit”). However, a question arises \u2013 what happens if our button has different text, for instance, due to issues displaying special characters? We get a negative result in a test that creates a user even though the string (commonly known as a “string”) we are searching for is different.<\/p>\n\n\n\n What can we do in this situation? We should write a better test<\/strong>! We can use the cy.get() method and provide our unique identifier (cy-data locator) here. This method eliminates the need to search for elements by a specific string and instead refers to the locator. However, we sometimes use the cy.contains() method because it is more convenient and effective than cy.get().<\/p>\n\n\n\n But what if we had a component test that generates this element with the expected string, simultaneously checking its text, behavior, and CSS styles? Our continuous integration tool would only allow further tests to run if we fixed what produced a negative result. Thanks to early error detection, we can quickly and cheaply fix it. Additionally, this prevents false negatives in other tests where the component is at fault, not the logic of the code itself.<\/p>\n\n\n\n The Testing Pyramid is a “design pattern” that outlines the hierarchy and quantity of tests. According to generally accepted standards, it is divided into three levels, stacked one on top of the other, in order of creation\/maintenance cost or execution time.<\/p>\n\n\n\n Developers usually write these and aim to verify a method\/function\/module at a unit level. They should have the highest, realistic code coverage. Unit tests are represented as the foundation of the testing pyramid because:<\/p>\n\n\n\n They can also serve as a form of project documentation.<\/p>\n\n\n\n At the next level are integration tests, which include system, functional, and integration tests. These tests verify whether individual modules communicate with each other using both test and real data. These tests are primarily written and executed by testers, but this also depends on team agreements and project approach. Depending on complexity, they may rely on external services but are certainly cheaper and faster than end-to-end tests (E2E).<\/p>\n\n\n\n These tests verify business paths from user creation to purchasing items in an online store. However, they have the following disadvantages:<\/p>\n\n\n\n Based on what we’ve read about both component tests and the Testing Pyramid, they sit between the unit and integration layers. This is precisely where I place them.<\/p>\n\n\n\n Here, we encounter a situation similar to that of unit tests. Internet sources claim that developers are responsible for component tests. However, I know from experience that most developers focus more on code implementation than writing tests. This is also a debatable topic related to the definition of done, project approach, and team dynamics.<\/p>\n\n\n\n In my opinion, writing component tests is an ideal task for a tester who wants to start their journey with automated testing. These tests are easy to write and maintain, and their results are clear, reliable, and transparent.<\/p>\n\n\n\n Here, I will discuss two approaches: the old and the new way of creating component tests using JavaScript with Cypress.<\/p>\n\n\n\n This approach is encountered in Cypress and other testing frameworks where we cannot currently display components. Knowing these limitations, let’s proceed with implementation.<\/p>\n\n\n\n We want our test to verify if our website’s “Click me” button meets our expectations. We need to check the button on our locally running software version at http:\/\/localhost:4200\/<\/a>.<\/p>\n\n\n\n We create test cases and check if it works.<\/p>\n\n\n\n The presented code looks neat and readable. Using the Page-Object design pattern and pulling recurring elements into variables can make it even clearer. Its drawback is undoubtedly the execution time, which, with four tests, is only 809 ms or as much as 809 ms.<\/p>\n\n\n\n Here, we need to note that we access the button immediately after loading “localhost.” It does not require any additional interaction, allowing us to achieve an acceptable time for four test cases. However, it becomes more complicated to extract individual elements, for example, from the third page of the user edit form to reach the reset button, which only appears after editing any field.<\/p>\n\n\n\n Suddenly, your test looks like this:<\/p>\n\n\n\n Acquiring this element can take a lot of time, leading to a significant increase in code and dependence on other services. What if we were to test the button on the “production” server? It took me 12 seconds to execute these four tests.<\/p>\n\n\n\n With this method, we can generate the component individually by importing it and passing it to the mount() method. It saves time on writing and execution, keeps the code clear, and ensures reliable tests. The time I achieved was 162 ms! This is the best result so far.<\/p>\n\n\n\n Component testing is not limited to Cypress alone. There are several alternative tools, such as<\/p>\n\n\n\n which can also be effectively used for this practice.<\/p>\n\n\n\n These diverse options allow developers to tailor tools to specific project needs, which becomes particularly important in situations where Cypress, for various reasons, does not meet expectations.<\/p>\n\n\n\n ***<\/p>\n\n\n\n Learn more about Cypress in other articles by our experts<\/a>.<\/p>\n\n\nComponent testing vs. the Testing Pyramid<\/strong><\/strong><\/h2>\n\n\n\n
<\/a>Unit test<\/strong>s<\/h3>\n\n\n\n
\n
Integration tests<\/strong><\/h3>\n\n\n\n
End-to-end tests<\/strong><\/h3>\n\n\n\n
\n
Where do component tests fit into the testing pyramid?<\/strong><\/h3>\n\n\n\n
<\/a>Who should write\/create component tests?<\/strong><\/h2>\n\n\n\n
Component tests in practice<\/strong><\/h2>\n\n\n\n
Old-fashion way<\/strong><\/h3>\n\n\n\n
<\/a>\n
<\/a><\/figure>\n\n\n\n<\/a><\/figure>\n\n\n\nWhat can we do to make our test better and faster?<\/strong><\/h2>\n\n\n\n
\n
<\/a><\/figure>\n\n\n\n<\/a>If not Cypress, then what?<\/strong><\/h2>\n\n\n\n
\n