Contributing to Meshery's End-to-End Tests using Cypress
Introduction
To automate functional integration and end-to-end testing through Meshery UI, Cypress is leveraged as it allows for both UI Integration & End-to-end test scripting with javascript through its modern features and supported test types.
Understanding the test framework directories
Clone the meshery/meshery repo and navigate to the /ui/cypress/ 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
│ │ ├── service_mesh_configuration_management_spec.js
│ │ ├── settings_spec.js
│ │ └── userpreference_spec.js
│ ├── integration
│ │ ├── configuration_filters_spec.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.
Directory: ./actionHelpers/ (code)
Helpers to provide common UI or API level actions across our different cypress integration and end-to-end tests.
Directory: ./fixtures/ (code)
Our Fixture Files which are used by our tests as:
- external pieces of static data to Stub response data in integration tests (i.e. /integration/integration/configuration_filters_spec.js)
- or reuse data as test input in end-to-end tests (i.e. /integration/e2e/service_mesh_configuration_management_spec.js).
Directory: ./integration/integration/ (code)
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 this guidance 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.
Directory: ./integration/e2e/ (code)
End-to-end tests for both Meshery UI and Meshery Server where its usually necessary to seed data, ocassionally bypass our UI, use actual server responses and define cypress routes to wait and assert on requests and/or their responses.
Directory: ./plugins/ (code)
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.
Directory: ./support/ (code)
This is where Meshery’s Cypress supportFile resides (./support/index.js). It’s processed and loaded automatically before tests run and it imports our ./support/commands.js file which allows us to sparingly define our Cypress Custom Commands to reuse functions needed across most or all test suites.
How to manually run end-to-end tests
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:
Run Meshery UI dev server and Cypress
If its the first time you’re opening cypress:
cd ui && npm i && npm run cy:dev:open
Else, just run:
npm run cy:dev:open
keep in mind that if running integration tests (tests in ./integration/integration/ folder) the server doesn’t need to be running but for full blown end-to-end tests (tests in ./integration/e2e/ folder) its recommended to run make server OR make sure a Meshery user build (see Getting Started) is installed and running locally before choosing one of those tests.