Skip to content

Testing Deployments Using Cypress📜

Table of Contents📜

  1. Introduction
  2. Extending Cypress Tests
  3. Resources

Introduction📜

Big Bang leverages a sub-chart called Gluon to perform both scripted and User Interface (UI) tests of deployed applications. This guide is designed to describe the basics of the UI testing portion of Gluon and how it can be extended to suit your needs.

The UI testing is performed via a container running Cypress and can be enabled on a per-package level by setting the value of bbtests.enabled to true. Be sure to review the values for each package as there may be additional settings related to the Cypress test under the bbtests.cypress section. With the correct values in place, you can run a test by specifying the following command:

helm test kiali-kiali -n bigbang

> **NOTE:** You can run the following command to grab the proper names for each helm chart deployed in Big Bang: "helm list -n bigbang."

Upon running the command, a new pod will be created in the same namespace as the package. This pod will install Cypress, download a Cypress configuration file, download a file that contains custom Cypress commands, and run any available tests. In order for the Cypress pod to run successfully, it needs to have external access to the internet and any resources it is attempting to reach out to for testing. This communication should be allowed by default. You may also need to add exceptions if using Kyverno or Gatekeeper within Big Bang. Links to these exceptions required can be found below in the Resources section.

Default Configuration Options📜

All Cypress tests use the same shared configuration file which can be found here. These values can be overridden by using additional environment variables under the bbtests.cypress.envs section for any given package. This same process can be used to specify and custom variables that may be need for custom Cypress tests you would like to deploy.

Additionally, test isolation has been disabled by default within Big Bang’s implementation of Cypress as each test is already isolated to a specific package. Disabling test isolation means that session and cookie information will persist within that Cypress pod from test to test instead of being wiped clean after each test. However, this behavior can be mitigated by leveraging a custom command that is available as part of the deployment:

cy.clearAllUserData()

The above command can be executed either at the beginning to ensure a clean session or at the end of any given test to ensure everything is clean before the next test.

Extending Cypress Tests📜

If the default provided Cypress tests are not enough for your installation of Big Bang, there are two options available to extend the behaviour to suit your needs:

Option 1: Augment Default Tests with Custom Cypress Tests📜

Adding your own Cypress tests can be done by creating a ConfigMap inside the namespace for the applicaiton that is being tested. As an example, let’s assume you have the following contents in a file called myConfig.yaml:

apiVersion: v1
data:
  10-custom.cy.js: |-
    describe('Dummy Cypress Test', () => {
      it('Custom Cypress Test', () => {
        cy.wait(10000)
      })
    })
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/component: server
  name: custom-script

This ConfigMap could be deployed to the kiali namespace by executing the following command:

kubectl apply -f myConfig.yaml -n kiali

Once the ConfigMap has been created, you need to specify the name of the ConfigMap in values.bbtests.cypress.customTest as a string for the application:

values:
  bbtests:
    cypress:
      customTest: "custom-script"

With the above in place, run the helm test command against the helm chart and the Cypress pod will pull in that ConfigMap as an additional Cypress test to run. It is recommended that any custom tests are prefixed with 10 or a higher number as our default tests start with 01. Some packages have multiple tests, but none of them go as high as 10, so this will guarantee your custom script runs after the default Cypress tests. If, for any reason, you need to make sure your custom test runs prior to our default tests, you can prefix the name of the file with 00.

Additionally, you can create any variable you may need within your Cypress tests by specifying the value or values under the bbtests.cypress.envs section as mentioned previously. For example, if you want to store a url in a variable, your test may include the following:

cy.visit(Cypress.env('my_custom_url'))

The values portion including the variable would look like this:

values:
  bbtests:
    cypress:
      customTest: "custom-script"
      envs:
        cypress_my_custom_url: "http://someurl.com"

Option 2: Use Only Custom Cypress Tests📜

This option is the same as the above, but allows you to completely disable the default provided Cypress tests and use only custom Cypress tests. This may be useful if any of the default tests are testing functions that have been disabled in a given application or if the UI has been customized to a point where the default tests simply don’t work. To use only a custom Cypress test with default tests disabled the application would need the following values specified:

values:
  bbtests:
    cypress:
      customTest: "custom-script"
      disableDefaultTests: true

When using this option, the names of the files can be whatever you want as ordering is no longer necessary. However, all custom Cypress test files must end with the .cy.js extension in order to be properly moved over to the Cypress pod.

Example Use Case📜

The easiest way to leverage custom Cypress tests in a Big Bang environment is to deploy the tests using Kustomize. Here is a sample folder structure of what that might look like:

|-- bigbang
|  |-- kustomization.yaml
|  |-- tests
|  |  -- 10-additional-neuvector-test.cy.js
|  |  -- 10-additional-tempo-test.cy.js

The contents of the kustomization.yaml file would be as follows:

generatorOptions:
  disableNameSuffixHash: true
configMapGenerator:
  - name: custom-script
    namespace: neuvector
    files:
    - tests/10-additional-neuvector-test.cy.js
  - name: custom-script
    namespace: tempo
    files:
    - tests/10-additional-tempo-test.cy.js

The following command can be used to deploy prior to running any helm tests:

kubectl kustomize ../bigbang

Resources📜

Gluon Package In Depth BB Test Documentation Kyverno Exceptions for Cypress Gatekeeper Exceptions for Cypress Cypress Environment Variables