Project: Meshery (Provisioning / Automation & Configuration)
File: contributing-cypress.md

layout: page title: Contributing to Meshery's End-to-End Tests using Cypress permalink: project/contributing/contributing-cypress abstract: How to contribute to End-to-End Tests using Cypress. language: en type: project category: contributing list: include To automate functional integration and end-to-end testing through Meshery UI, is leveraged as it allows for both UI Integration & End-to-end test scripting with javascript through its and . Clone the `meshery/meshery` repo and navigate to the directory. ``` . actionHelpers service-mesh-configuration-management.js fixtures clusterVersion.json configuration example.json getMeshAdapters.json postMeshManage.json stats.json sync.json integration e2e lifecyclecheck_spec.js servicemeshconfigurationmanagementspec.js settings_spec.js userpreference_spec.js integration configurationfiltersspec.js discoverCluster_spec.js indexui_spec.js settings_spec.js userpreference_spec.js sample_spec.js plugins index.js support commands.js index.js ``` Let's walk-through each of these directories and comprehend their purpose. Helpers to provide common UI or API level actions across our different cypress integration and end-to-end tests. Our which are used by our tests as: external pieces of static data to response data in integration tests (i.e. ) or reuse data as test input in end-to-end tests (i.e. ). Integration tests for Meshery UI that stub server requests to: Prevent state mutation across tests. Build the way we want the data to be structured without contract of server being available. Test critical edge cases without server, etc. Follow regarding when it's a good idea to stub the server versus allowing the frontend to reach out the actual server and its underlying resources. End-to-end tests for both Meshery UI and Meshery Server where its usually necessary to , occasionally , use and define cypress to and on requests and/or their responses. Define Cypress plugins to leverage as "Seams" for Meshery's workflows to run the project's own custom code to execute during particular stages of Cypress lifecycle. This is where Meshery's Cypress supportFile resides (). It's processed and loaded automatically before tests run and it imports our file which allows us to sparingly define our Cypress to reuse functions needed across most or all test suites. Steps to start Cypress depend on whether your Meshery installation is built from source code or from a deployed release. The following steps try to simplify the former which should be the most frequently needed scenario: If its the first time you're opening cypress: {% include code.html code="cd ui && npm i && npm run cy:dev:open" %} Else, just run: {% include code.html code="npm run cy:dev:open" %} {%include alert.html content="Note the difference between local dependencies for Integration vs End-to-End Tests" %} keep in mind that if running integration tests (tests in folder) the server doesn't need to be running but for full blown end-to-end tests (tests in folder) its recommended to run `make server` OR make sure a Meshery user build (see ) is installed and running locally before choosing one of those tests.