Skip to content

Latest commit

 

History

History
76 lines (51 loc) · 3.22 KB

testing.adoc

File metadata and controls

76 lines (51 loc) · 3.22 KB

testing Guide

Testing guide

This project uses the Go standard testing module for running tests and contains high level descriptions of the testing deployment styles.

This guide is technical in nature and is aimed at readers with experience in cluster computing and operating multi-server solutions.

The tests for this project are self provisioned tests and use full implementations of their dependencies rather than mocking. Unit tests are designed to be run in a standalone environment without dependencies deployed. If dependencies are needed they will be initialized as subprocesses, for example the minio server is spun up as a dependency. In full end-ot-end testing a Kubernetes cluster should be used with dependencies run as deployments.

CI Testing

TBD

Unit testing

TBD

End to end testing

End to end testing is typically performed during CI builds and relies on the presence of a Kubernetes cluster that the build system is given credentials to.

End to end testing can be manually performed as well by deploying a local RabbitMQ server. minio servers can be started by the runners internal testing system. Because the minio servers are started in the background it is important that none of the MINIO environment variables are present when starting the test as they will override the auto generated passwords etc of the test.

export AMQP_URL=amqp://guest:[email protected]:5672/
sudo invoke-rc.d rabbitmq-server start
go test -v -tags=NO_CUDA -a -cache-dir=/tmp/cache -cache-size=1Gib -test.timeout=10m -test.run=TestÄE2ECPUExperiment -limit-interval=15s -limit-idle-duration=60s --use-k8s --skip-k8s

To cleanup queues after testing the following command can be used:

sudo rabbitmqctl --quiet list_queues name --no-table-headers | xargs -n 1 sudo rabbitmqctl delete_queue

One and done style limit testing

One special case test available within the system, TestĆLimiterShutdown, can be used to to test runtime limits for the number of tasks performed and idle timers.

The following commands shows the limiter test being used for idle timeouts.

go test -v -tags=NO_CUDA -a -cache-dir=/tmp/cache -cache-size=1Gib -test.timeout=10m -test.run=TestĆLimiterShutdown -limit-interval=15s -limit-idle-duration=60s --use-k8s --skip-k8s

To perform the tasks limit test using a single CPU experiment the following command can be used, the CPU test named in this command will invoke the test which upon seeing the job limit will pause and see if the shutdown occurs.

go test -v -tags=NO_CUDA -a -cache-dir=/tmp/cache -cache-size=1Gib -test.timeout=10m -test.run=TestĆLimiterShutdown --limit-tasks=2 --limit-interval=15s --limit-idle-duration=60s --use-k8s --skip-k8s