cypress-testing.md

revision_date: Last edited April 2, 2024
tags:
  - blog

Cypress Testing In-Depth

Introduction

The intent of this post is to build off the existing Cypress Testing documentation here and go a bit deeper into how it can be leveraged in a real-world environment. We will also go a bit deeper into Cypress specific configuration settings, running/debugging tests, and cover some of the basics of Cypress.

Environment Overview

Before we get started, let's go over the environment we'll be using. This environment was setup using the umbrella strategy described in our Customer Template and has the following layout:

|-- bb-demo
|  |-- base
|  |  |-- cypress-tests
|  |  |  |-- sonarqube
|  |  |  |  -- 10-sonarqube-health.cy.js
|  |  |  |  -- 11-sonarqube-delay.cy.js
|  |  -- configmap.yaml
|  |  -- kustomization.yaml
|  |  -- secrets.enc.yaml
|  |-- demo
|  |  -- bigbang.yaml
|  |  -- configmap.yaml
|  |  -- kustomization.yaml
|  |  -- secrets.enc.yaml

As this is only a demo, there is only one environment named demo, but in a real-world situation you would likely have additional folders for staging and production. The custom Cypress tests are located under the base folder as these would remain the same regardless of the environment to which they are being deployed. The configuration of the environment itself is pretty straight forward and primarily contained in the configmap.yaml under the demo folder:

domain: dev.bigbang.mil
networkPolicies:
  enabled: true
neuvector:
  enabled: false
kyvernoPolicies:
  values:
    validationFailureAction: Audit
addons:
  sonarqube:
    enabled: true
    values:
      bbtests:
        enabled: true
        cypress:
          artifacts: false
          disableDefaultTests: true
          customTest: "sonarqube-tests"
          resources:
            requests:
              cpu: 2
              memory: "4Gi"
            limits:
              cpu: 4
              memory: "8Gi"
          envs:
            cypress_user: "admin"
            cypress_url: "https://sonarqube.dev.bigbang.mil"
            cypress_url_setup: "https://sonarqube.dev.bigbang.mil/setup"
          secretEnvs:
            - name: cypress_password
              valueFrom:
                secretKeyRef:
                  name: sonarqube-secrets
                  key: password

We'll go over the more specific configuration settings for Cypress later, but for now let's continue to the rest of the configuration. The kustomization.yaml under the demo folder holds an additional reference to a kubernetes secret created to hold the password for the sonarqube user:

generatorOptions:
  disableNameSuffixHash: true
bases:
- ../base
configMapGenerator:
  - name: environment
    behavior: merge
    files:
      - values.yaml=configmap.yaml
secretGenerator:
  - name: sonarqube-secrets
    namespace: sonarqube
    files:
      - password=secrets.enc.yaml

The kustomization.yaml file under the base folder has also been modified to reference the Cypress test files we want to use:

generatorOptions:
  disableNameSuffixHash: true
bases:
- https://repo1.dso.mil/platform-one/big-bang/bigbang.git//base?ref=2.23.0
configMapGenerator:
  - name: common
    behavior: merge
    files:
      - values.yaml=configmap.yaml
  - name: sonarqube-tests
    namespace: sonarqube
    files:
      - cypress-tests/sonarqube/10-sonarqube-health.cy.js
      - cypress-tests/sonarqube/11-sonarqube-delay.cy.js
patchesStrategicMerge:
- secrets.enc.yaml

Both kustomization.yaml files have an additional option at the top to disable the name suffix hash to ensure we can reference it correctly. The assumption of this environment is that Sonarqube has been enabled and configured.

Cypress Specific Settings

Aside from enabling the tests themselves, there are a few settings that deserve more attention:

• artifacts - This setting is typically set to true when running tests from a pipeline. However, since we are running this in a local dev environment we have set the value to false. It's worth noting that when this value is true a host path mount called Cypress will need to be created and available within your Kubernetes cluster. This allows the pod to upload any of the resulting screenshots and videos from the cypress tests before the pod completes.

• resources - Cypress recommends 2 CPU's and 4 GB of RAM at an absolute minimum with more given depending on the complexity and length of the tests themselves. At the time of this writing, the default values for both requests and limits for CPU and Memory are 1 and 2 GB respectively as many of the default tests are very basic. The settings used in the configmap.yaml previously shown are just there for demo purposes and are likely much more than what is needed for our tests. However, if you ever find yourself running into odd issues that only seem to come up in your tests, it may be a good idea to tweak those values first to make sure its not the cause. This is especially true if you find that the logs indicate the browser crashed during a test as that is the most common sign of not having enough resources.

• envs - This is where you would specify any environment variables that will be used by your Cypress tests. You'll want to check each package where tests are enabled to see what variables are required if you're using the default provided tests. You can also add in any additional variables you need for any custom tests you've written. Any variable prefixed with "cypress_" will become a variable you can use in your tests. For example, the existing variable of "cypress_user" shown above, can be used within your Cypress test by referencing the "user" variable which you'll see a bit later.

• secretEnvs - The same rules apply to this setting, but these values are pulled from Kubernetes secret files so they'd likely be used for any passwords or tokens you may need to use throughout any tests.

We won't go over the customTest and disableDefaultTests settings as this has already been explained in the documentation link referenced in the Introduction section.

Cypress Tests

Now that we've covered the environment and settings, let's take a look at the Cypress tests themselves. In this specific scenario, we've come to the realization that the default tests don't quite offer all we need to be satisfied. As a result, we've decided to disable the default tests and create a very basic health check: