I like tests. For me, they’re the only way to prove your code does what you claim it does.

This is why I like a “Tests as Spec” approach for my work. Any ticket I create, where possible, I like to specify the tests as part of the success criteria. The format doesn’t matter, it can just be rough pseudocode that the developer can translate into unit tests, or even high level Behaviour Driven Design tests written in something like Cucumber or Robot Framework.

I had one such task. We had a problem in our system and set about creating a solution. We agreed it could be filled with a new microservice. The specifications for the new service were discussed with the QA team, and in a 3 amigex session we created a set of behavioural tests that formed the acceptance criteria for the task.

I wanted these tests to be included in the pipeline, as part of our automated testing strategy.

There’s many ways to achieve this, but I wanted to test this in a way that replicated the service as it would be in production. Our production environment was in Kubernetes using Kustomize scripts to specify the deployment of the services.

After creating an initial vertical slice draft of the service I could create the Kustomize deployment so the general shape of the service was clear to see. I could already use kubectl to deploy the service to a locally running minikube to replicate how it would be deployed in the production Kubernetes cluster. With that, it was possible to run the Cucumber scripts composing our BDD tests and prove the functionality we had desired. But this was all manual, the next step was to automate this in the pipeline.

So that’s what we did. We created a GitHub Action pipeline that starts up a minikube cluster; deploys the service under test using the same Kustomize script that will be used to deploy it to production; deploy a mocked version of a service that will fulfil it’s external dependency; and finally a Cucumber container with the BDD feature scripts loaded into it that it will run on startup. We called this container simply “bdd-tester”. It will be built in the pipeline and never be pushed to a repository as there is no need for it to exist outside of the testing pipeline.

Below are the relevant files you can use for building this system yourself. I have omitted the service under test, but suffice to say it was a simple REST API with some business logic contained inside.

Below is the Dockerfile for the bdd-tester. We utilised Cucumber for the runtime and Typescript for support code. So for the container, it’s a simple matter of copying in the features directory, along with the Cucumber and Typescript configuration files, and installing the Cucumber library.

Here is the Kustomize script for the bdd-tester deployment. The RUN_IN_K8S environment variable was a simple way to let the test support code know which URL to target in regards to the external dependency service, as the services and tests can be run locally or inside of Kubernetes.

And finally, the GitHub Action pipeline for building the image, starting minikube, loading all the images, starting the deployments and awaiting for the results. The bdd-tester and related Cucumber feature files lived in a directory called “integration-tests”.

Hopefully the GitHub Action is self-explanatory and you are able to utilise it for yourselves.

If you have any questions or want to hear more about Hivemind’s ways of working, please feel free to reach out to me on LinkedIn.