Testing workflow

This guide explains how to run the local testing workflow using kind (Kubernetes in Docker) and DevSpace. For local development, we use a kind cluster to simulate a Kubernetes environment. kind is a lightweight tool that runs a Kubernetes cluster inside Docker containers on your local computer. This document represents the default workflow. If a particular image diverts from this, it should be documented in the per image documentation found in Components.

ATKK Devspace Configuration Guide

If working from ATLNZ, you can ignore this section.

There is some added difficulty for ATKK network environments, as they use a corporate HTTP_PROXY that sits on top of their network. This proxy gets information in via the environment variables.

The test system loads these environment variables from /etc/environment file in host environment. So that the following directives must be written in this file to run the test correctly.

# Please add the following environment variable definitions to the /etc/environment file.
HTTP_PROXY="http://http-gw2.allied-telesis.co.jp:3128"
http_proxy="http://http-gw2.allied-telesis.co.jp:3128"
HTTPS_PROXY="http://http-gw2.allied-telesis.co.jp:3128"
https_proxy="http://http-gw2.allied-telesis.co.jp:3128"
no_proxy="localhost,127.0.0.1,::1,.allied-telesis.co.jp,.atlnz.lc"
NO_PROXY="localhost,127.0.0.1,::1,.allied-telesis.co.jp,.atlnz.lc"

Using DevSpace

DevSpace synchronises the source code on your local computer directly into the application containers running inside Kubernetes pods in the kind cluster. This lets you develop and test without rebuilding the image or redeploying the pod for every code change. This feature, called hot reloading, enables faster feedback. The behavior is configured in the devspace.yaml file.

Here are the steps for running DevSpace for testing:

Start the repository’s build environment. This environment has kind and DevSpace pre-installed and configured, so you can create a local Kubernetes cluster and run the DevSpace pipelines.
For the example-service repository, run this command:
```
./devEnv.sh
```
Bring in the dependencies.
```
yarn
```
Build application. This copies code to the 'dist' folder, to be used in later steps as location to build images from.
```
yarn run build
```
When it run devspace script on ATKK network, it must specify devspace-atkk.yaml by using shell environment variable.
```
# Run this command only on ATKK network.
export DEVSPACE_CONFIG=./devspace-atkk.yaml
```
Remove the local test cluster. This deletes the test-workload cluster from the local kind environment created for testing . This ensures a clean Kubernetes environment and prevents conflicts caused by leftover resources between test runs. If the test-workload cluster does not exist, the command exits without error.
```
devspace run stop
```
Start cluster and run test pipeline. This creates a new cluster named test-workload in the local kind environment and runs the DevSpace test pipeline in it. The test pipeline deploys the Kubernetes resources defined in manifests/overlays/test/kustomization.yaml, deploys a test-runner, and enables DevSpace file synchronization for both the workload under test and the test-runner. The tests do not execute inside the workload container. Instead, they run in the test-runner pod, interacting with the workload over the cluster network, ensuring separation between application and test execution.

[!IMPORTANT]

Each development location running this kind may need (for speed purposes) to provide there own kind-[center-name]-config.yaml stating where images are to be obtained. In the case of the NZ configuration; the file kind-atlnz-config.yaml is used.

KinD - Registry Mirror Patching

devspace run start

Wait until the test-runner and the workload (e.g. asset-management-view) file sync process completes.

For the test-runner, wait for this log to appear:

dev:test-runner sync  Initial sync completed

For the workload, e.g. asset-management-view, wait until these logs start showing:

dev:asset-management-view logs  Starting application...
dev:asset-management-view logs  {"level":"info","time":1772415208727,"pid":197,"hostname":"asset-management-view-devspace-656d65598d-fm92f","module":"index","msg":"Starting server"}

After the above steps have been completed, we have a cluster named test-workload running in our local kind instance. In this cluster, there is a special test-runner pod running. The pods in the deployment we are testing are essentially running the local code on our PC. Once that is setup, testing activity and TDD can begin.

Troubleshooting Tip

If you encountered an error when starting the pipeline, for example, it complains about too many files are opened during syncing, you can try clearing everything from your docker environment and restarting the computer.

Open a new terminal for the below tests

Below are the different tests you can run. If prompted to select a namespace, choose test.

Run all tests
```
devspace run test
```
Run all tests in watch mode. All test will automatically re-run after code or test change. Good for TDD.
```
devspace run watch
```
Run all cluster tests (Tests tagged with @cluster)
```
devspace run cluster
```
Run other non-cluster unit tests (Tests tagged with @unit)
```
devspace run unit
```
Clean-up and remove the kinD cluster after tests
```
devspace run stop
```

Other DevSpace pipelines

In DevSpace, a pipeline is a user-defined, ordered sequence of commands that DevSpace executes. When the user runs devspace run-pipeline <pipeline-name> -n <your-namespace>, the specified pipeline with its commands will run. These commands can include installing dependencies, building images, deploying resources to the cluster, syncing local changes to a specific pod for development, executing tests, and cleaning up.

The above tests run from the test pipeline. Here is an overview of the available pipelines: test and ci:

The `test` pipeline

devspace run-pipeline test

Note: devspace run start runs this pipeline.

The test pipeline deploys the workload under test and a separate test-runner into a local Kubernetes cluster. It can also deploy supporting services such as mock-onboarding-proxy-service, mongodb, nat-consumer, and nats-stream. This setup allows tests to run against the workload in a local environment that simulates the deployment environment.

The `ci` pipeline

devspace run-pipeline ci

The ci pipeline builds and loads into the KinD cluster an actual image of the workload under test (rather than syncing code to the cluster) then runs the cluster tests. It is used in the Jenkins pipelines for the image.