{"id":512671,"date":"2022-09-01T15:58:10","date_gmt":"2022-09-01T14:58:10","guid":{"rendered":"https:\/\/www.devoteam.com\/expert-view\/practical-guide-to-end-to-end-testing-with-cypress\/"},"modified":"2022-09-01T15:58:10","modified_gmt":"2022-09-01T14:58:10","slug":"practical-guide-to-end-to-end-testing-with-cypress","status":"publish","type":"expert-view","link":"https:\/\/devoteam.info\/cz\/expert-view\/practical-guide-to-end-to-end-testing-with-cypress\/","title":{"rendered":"A Practical Guide to End-to-End Testing with Cypress"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

The front-end is the client-side part of your application.<\/p>\n\n\n\n

Everything that is visible to your users is part of the front-end.<\/p>\n\n\n\n

To put it in other words \u2014 front-end testing is about graphical user interface (GUI) testing.<\/p>\n\n\n\n

So you get a better picture, if you are developing an online shopping platform, frontend testers check whether the look and feel of the website are aligned with the requirements. Also, they make sure things work properly and feel the way the user experience designer envisioned it.<\/p>\n\n\n\n

Why is front-end testing so important?<\/h2>\n\n\n\n

Well\u2026 because our end users<\/a> judge the book by its cover and have no clue about the back-end side of things, they only notice when there\u2019s some issue they can see. Hence problems in the UI stick out and get noticed immediately. A company that wants to be successful thus needs to provide a great and consistent user experience. This means making sure that the application runs fast and without error, no matter which device or browser is used.<\/p>\n\n\n\n

What is automated front-end testing?<\/h2>\n\n\n\n

Probably you are already familiar with manual testing. For example, you have implemented an input field into a form. Afterwards, you open the webpage click into the input field to check whether it works and submit the form. This was a manual test. Performing this test for everything you implement over and over again is tiresome and not scalable. At a certain point, you would have no time to implement anything anymore and would spend all day testing. This is where automatization comes into play. Using automated concepts we can be sure that features will continue to work as they should.<\/p>\n\n\n\n

Automated tests also help especially with so-called edge cases. Use cases we tend to forget, like checking a box for some signup process.<\/p>\n\n\n\n

What are the top reasons to automate testing?<\/h3>\n\n\n\n
    \n
  1. Update your code with confidence!<\/strong> Good tests allow you to refactor code with confidence that you are not breaking any functionality and without changing the tests.<\/li>\n\n\n\n
  2. Documentation included, for FREE!<\/strong> Tests come in handy because they explain how your code works with its expected behaviour. Tests, not like written documentation often, have to be always up to date.<\/li>\n\n\n\n
  3. Bugs are gone forever \u2014 almost!<\/strong> By writing up test cases for every bug, you can be sure that these will never come back. Further writing tests will improve your understanding of the code and the requirements. Using testing you might find issues that you could miss otherwise.<\/li>\n<\/ol>\n\n\n\n

    What is being tested in front-end testing?<\/h2>\n\n\n\n

    UNIT TESTS<\/strong><\/h4>\n\n\n\n

    These are focused on the smallest entity of your front-end applications.<\/p>\n\n\n\n

    Usually, these are components in the React context, but cover interfaces, classes and methods. These simple and small tests check whether the output of a small part equals the expected. The checks are predefined and completely isolated.<\/p>\n\n\n\n

    INTEGRATION TESTS<\/strong><\/h4>\n\n\n\n

    Like the name suggests, these type of tests put multiple code components together and test their interaction. In React these are usually built of views that integrate multiple components.<\/p>\n\n\n\n

    END-TO-END TESTS<\/strong><\/h4>\n\n\n\n

    These tests are the holy grail since they are testing the application. Let’s dive in a littler further on end-to-end testing. <\/p>\n\n\n\n

    What is end-to-end testing?<\/h2>\n\n\n\n

    End-to-end testing or user interface testing is an approach to testing a web application. An end-to-end test verifies that a web application meets the requirements and works as expected. The so-called “user flow” is tested. End-to-end testing is important! But nobody likes it…They can be extremely cumbersome and very time-consuming. On the other hand, only testing can provide confidence in the final product. In the end, testing ensures that we don’t release a broken product to our users.<\/p>\n\n\n\n

    What is Cypress?<\/h2>\n\n\n\n

    Cypress, featured on TechRadar<\/a> by Devoteam, is a free, open-source automation testing tool built for modern web applications based on modern frameworks like React. It provides a UI to show what tests and commands are running, passing and\/or failing.<\/p>\n\n\n\n

    But isn\u2019t there Selenium? <\/strong><\/h3>\n\n\n\n

    Every developer has suffered before configuring Selenium. There are a multitude of steps, often extremely confusing, where we need compatible versions of Java, drivers, browsers, even Selenium itself, etc… It’s just exhausting! Not to mention that many front-end developers don’t necessarily want to use Java. Additionally, Cypress easily outperforms Selenium in terms of speed, reliability, and ease of use.<\/p>\n\n\n\n

    Cypress Installation & Configuration<\/h2>\n\n\n\n

    Cypress comes with some documentation dedicated to visual testing<\/a> and a list of all available plug-ins<\/a> to help configure it for visual regression testing.<\/p>\n\n\n\n

    We decided to choose cypress-plugin-snapshots<\/a> because of the ease of use and amount of time needed for the initial setup. There are many great tools & libraries out there, so check them out!<\/p>\n\n\n\n

    We simply installed the npm library like so:<\/p>\n\n\n\n

    npm install cypress cypress-plugin-snapshots<\/a><\/em><\/p>\n\n\n\n

    And this is how a  cypress.json configuration can look:<\/p>\n\n\n\n

    {\n\u201cenv\u201d: {\n  \u201cTAGS\u201d: \u201cnot @ignore\u201d,\n  \u201ccypress-plugin-snapshots\u201d: {\n    \u201cautoCleanUp\u201d: true,\n    \u201cautopassNewSnapshots\u201d: true,\n    \u201cdiffLines\u201d: 3,\n    \u201cprettier\u201d: true,\n    \u201cimageConfig\u201d: {\n      \u201ccreateDiffImage\u201d: true,\n      \u201cresizeDevicePixelRatio\u201d: false,\n      \u201cthreshold\u201d: 0.025,\n      \u201cthresholdType\u201d: \u201cpercent\u201d\n    },\n    \u201cscreenshotConfig\u201d: {\n      \u201cblackout\u201d: [\u201c\u201d],\n      \u201ccapture\u201d: \u201cviewport\u201d,\n      \u201cdisableTimersAndAnimations\u201d: true,\n      \u201clog\u201d: true,\n      \u201cscale\u201d: false,\n      \u201ctimeout\u201d: 30000\n    }\n  }\n},\n\u201cbaseUrl\u201d: \u201chttp:\/\/localhost:9000\u201d,\n\u201cvideo\u201d: false,\n\u201cviewportWidth\u201d: 1920,\n\u201cviewportHeight\u201d: 1080,\n\u201ctestFiles\u201d: \u201c**\/*.feature\u201d,\n\u201crequestTimeout\u201d: 60000,\n\u201cignoreTestFiles\u201d: [\u201c**\/__snapshots__\/*\u201d, \u201c**\/__image_snapshots__\/*\u201d],\n\u201cchromeWebSecurity\u201d: false,\n}\n<\/pre>\n\n\n\n
    Why integrate Cucumber with Cypress?<\/h2>\n\n\n\n
    There are several tools for a behavior-driven development framework, but the most commonly used BDD tool is Cucumber<\/a>. BDD is a form of Test Driven Development (TDD). Human-readable descriptions of software requirements are used as the basis for tests. This approach helps us to write the tests in a common vocabulary for all project participants. For this reason, even someone without a developer background can get an idea of \u200b\u200bthe tests carried out.<\/p>\n\n\n\n
    Cucumber with Gherkin<\/h2>\n\n\n\n
    For Cypress we can only write our tests in Javascript \/TypeScript. However, if we want to use Cucumber, we convert the Java Script test to “Gherkin<\/a>” (the language for Cucumber). Gherkin mainly consists of the four main keywords: “Given”, “When”, “And” and “Then”. Using the keywords we can use the already used JavaScript code.<\/p>\n\n\n\n
    JavaScript end-to-end tests in Cypress<\/h2>\n\n\n\n
     {\n  it(\u201cCan fill out the form\u201d, () => {\n    cy.visit(\u201c\/\u201d);\n    cy.get(\u201cform\u201d);\n    cy.get(\u2018input[name=\u201dname\u201d]\u2019)\n      .type(\u201cDavid\u201d)\n      .should(\u201chave.value\u201d, \u201cDavid\u201d);\n    cy.get(\u2018input[name=\u201demail\u201d]\u2019)\n      .type(\u201cdavid@devoteam.com\u201d)\n      .should(\u201chave.value\u201d, \u201cdavid@devoteam.com\u201d);\n    cy.get(\u201ctextarea\u201d)\n      .type(\u201cThis is a test\u201d)\n      .should(\u201chave.value\u201d, \u201cThis is a test\u201d);\n    cy.get(\u201cform\u201d).submit();\n  });\n});\n\n<\/pre>\n\n\n\n
    <\/p>\n\n\n\n
    With just one look you can see that it will be very difficult for someone without developer knowledge to understand the pure test script.<\/p>\n\n\n\n
    The same with Cucumber and Gherkin<\/h2>\n\n\n\n
    \/\/integration\/formular\/form.ts\nimport { Before, Given, Then, When, And } from \u2018cypress-cucumber-preprocessor\/steps\u2019;\nGiven(\u201cWe visit the form page\u201d, ()=>{\n    cy.visit(\u201c\/\u201d);\n    cy.get(\u201cform\u201d);\n});\nWhen(\u201cwe enter the name {String}\u201d, (name) => {\n    cy.get(\u2018input[name=\u201dname\u201d]\u2019)\n      .type(name)\n      .should(\u201chave.value\u201d, name);\n});\nAnd(\u201cwe enter the email {String}\u201d, (email) => {\n    cy.get(\u2018input[name=\u201demail\u201d]\u2019)\n      .type(email)\n      .should(\u201chave.value\u201d, email);\n});\nAnd(\u201cwe enter the comment {String}\u201d, (comment) => {\n    cy.get(\u2018textarea\u2019)\n      .type(comment)\n      .should(\u201chave.value\u201d, comment);\n});\nAnd(\u201cwe submit the form\u201d, () => {\n    cy.get(\u201cform\u201d).submit();\n});\nThen(\u201cwe are on the home page\u201d, () => {\n    cy.url().should(\u201cinclude\u201d,\u201dstart\u201d);\n});\n<\/pre>\n\n\n\n
    The .feature test file<\/h2>\n\n\n\n
    Functionality:  Testing the form input\nScenario: F-01 Enter the form and submit\n Given we visit the form page\n When we enter the name \u201cDavid\u201d\n And we enter the email \u201cdavid@devoteam.com\u201d\n And we enter the comment \u201cThis is a Test\u201d\n And we submit the form\n Then we are on the home page<\/pre>\n\n\n\n
    \/\/integration\/form.feature
    #language: en<\/p>\n\n\n\n
    Functionality<\/strong>:  Testing the form input
    Scenario:<\/strong> F-01 Enter the form and submit
    Given <\/strong>we visit the form page
    When <\/strong>we enter the name “David”
    And <\/strong>we enter the email “david@devoteam.com”
    And <\/strong>we enter the comment “This is a Test”
    And <\/strong>we submit the form
    Then <\/strong>we are on the home page<\/p>\n\n\n\n
    However, if we now look at the test file with Cucumber, it becomes much simpler and more readable.<\/p>\n\n\n\n
    Some final words<\/h2>\n\n\n\n
    Cypress with Cucumber is a great test framework and in my opinion, has the following advantages:<\/p>\n\n\n\n