Local Test Development
If you're new to Testkube, make sure you have a thorough understanding of Test Workflows before diving into this topic.
While developing the actual tests being run with a Test Workflow (for example a Playwright test), it can be cumbersome to have to commit every change to git to be able to run tests via Testkube. While there is currently no built-in Workflow functionality that allows content retrieval from a local filesystem (instead of git), the approach outlined below shows how to achieve this with a local ftp server and a dedicated step in your Test Workflow that can be used to (optionally) override the test files retrieved from git with those retrieved from your local working copy.
The below approach is a temporary workaround for the lack of local-development functionality in Testkube, which is something we plan to support natively in the future.
Overview
The workaround consists of the following parts:
- A local FTP server that provides (preferably) read-only access to the folder containing the contents of the git
repository that your Workflow is using in its
spec.content.git
configuration - A first step in your Workflow that (optionally) retrieves the contents of your git repository via ftp from your local machine and therefore overrides any files initially cloned from the actual git repository.
- A local Kubernetes Cluster (minikube, kind, etc.) with a Testkube Runner Agent deployed.
This example uses FTP for convenience, but any client/server setup that allows for file transfer should work; sftp/ssh, etc.
1. Local FTP Server
In this example, we will use the Filezilla Server but any FTP Server should be sufficient.
- Install the server on your local machine and connect to it with the Filezilla Server Application.
- Configure the server by adding a user that has read-only access to your local folder containing the git repository referred to
by your Workflows
spec.content.git.uri
property
- Make sure to save the changes and (optionally) use an FTP client to validate that you can connect with the configured user and see the contents of the specified folder.
2. FTP Retrieval Step
Now let's add an initial step to our Workflow that uses lftp to retrieve the contents of our tests via ftp
into the /data/repo
folder where our initial repo has been cloned, which effectively overwrites any files cloned from git
with those in your local folders.
steps:
- name: Override tests from local folder
condition: config.localOverride
optional: true
container:
image: maurosoft1973/alpine-lftp
shell: lftp host.docker.internal -u testkube,testkube -e "
set ssl:verify-certificate no;
set xfer:log 1;
set xfer:log-file /dev/stdout;
mirror /test/playwright/playwright-project /data/repo/test/playwright/playwright-project;
quit"
A couple of notes:
condition: config.localOverride
is used to run this step only if thelocalOverride
config parameter istrue
- Read more.- The step is marked as
optional
to avoid the Workflow failing if the ftp retrieval fails for some reason, you might want to remove this if you want to be sure the ftp retrieval works when enabled - Read More. - The
shell
command invokeslftp
with thehost.docker.internal
hostname made available by Docker on MacOS - see below. - Make sure to set the username/password to the same you had configured in the FTP Server.
- The various
lftp
set
commands are used to disable SSL verification and configure logging so we can see which files that were transferred (see screenshot below)
Host Network Access
For the Workflow Step running the ftp client to be able to reach the ftp server running on your local machine, the local Kubernetes instance needs to mount your local (host) network into the network of the Kubernetes instance itself.
For example, pods running under Kind with Docker Desktop on MacOS can use host.docker.internal
to access the network of the hosting machine (as in the example below).
Refer to the documentation of your Kubernetes provider to find out the corresponding address/hostname (if available).
3. Testkube Runner Agent
Next, install a Testkube Runner Agent in your local Kubernetes cluster as described at Runner Agent Quickstart.
Once installed, you should see the Runner Agent in the list of Agents under your Environment:
When running your Workflow, make sure to run it on this Runner Agent as described at Running Workflows on Runner Agents.
Putting it all together
The below Workflow is essentially the in-product example Playwright Workflow - with the additional ftp-retrieval step added. This approach should work for any tests/scripts that are first cloned from git and then overridden by the ftp-retrieval.
kind: TestWorkflow
apiVersion: testworkflows.testkube.io/v1
metadata:
name: playwright-sample
namespace: testkube
labels:
docs: example
spec:
config:
localOverride:
type: boolean
default: "false"
content:
git:
uri: https://github.com/kubeshop/testkube
revision: main
paths:
- test/playwright/playwright-project
container:
workingDir: /data/repo/test/playwright/playwright-project
image: mcr.microsoft.com/playwright:v1.53.2-noble
resources:
requests:
cpu: 2
memory: 2Gi
steps:
- name: override latest from local
condition: config.localOverride
optional: true
container:
image: maurosoft1973/alpine-lftp
shell: lftp host.docker.internal -u testkube,testkube -e
"set ssl:verify-certificate no;
set xfer:log 1;
set xfer:log-file /dev/stdout;
mirror /test/playwright/playwright-project /data/repo/test/playwright/playwright-project;
quit"
- name: Install dependencies
shell: npm ci
- name: Run tests
shell: npx --yes playwright test --trace on
artifacts:
paths:
- playwright-report/**/*
Normal Execution
When running this Workflow you will be prompted to use the localOverride:
Which will run the Workflow as usual and skip the local-override step:
Execution with Local Override
If we instead set localOverride to true, we can see that the ftp-retrieval kicks in and overwrites the cloned repository with our local files:
We can also see this in the Filezilla log:
As you can see, the actual file retrieval is more-or-less instantaneous, which allows us to run our Workflow using our local files before committing them to git without any performance penalty.
Sequence Diagram
This high-level sequence diagram illustrates the execution of the Workflow:
Next Steps
If this approach is to your liking, you could extract the ftp-retrieval step into a WorkflowTemplate
that you include in your Workflows, providing a consistent mechanism for local development (you will still need to add the localOverride
parameter to your Workflow if you want to make this configurable).