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:

Directory: ./integration/integration/ (code)

Integration tests for Meshery UI that stub server requests to:

  1. Prevent state mutation across tests.
  2. Build the way we want the data to be structured without contract of server being available.
  3. 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, occasionally 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

Note the difference between local dependencies for Integration vs End-to-End Tests

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.

References