Local Testing
This guide gives a local test loop for contributors working in the
DTaaS monorepo. The authoritative build and test command for each project
is in the "Build and test commands" section of PROJECT.md; the commands
below follow it. The development container in developer/devenv/ has
every toolchain they need.
Recommended Order
- Run syntax and lint checks for the changed component.
- Run fast local tests (unit or focused integration).
- Run broader test suites before opening a pull request.
- Build the docs if markdown or navigation changed.
Client (React + TypeScript)
Run from client/:
yarn config:test copies the test configuration into public/env.js
and build/env.js. Use the yarn test:* scripts rather than bare
jest: they load the setup files that the tests depend on.
For end-to-end checks:
The end-to-end suite logs in through GitLab, so it needs a reachable
GitLab instance configured in client/test/.env. GitHub Actions does not
run it; run it locally before opening a pull request that changes
client behaviour. See client/test/README.md.
Library Microservice (NestJS)
Run from servers/lib/:
For API-level checks of the cloudcmd integration, use yarn test:http.
It needs a configured .env file and starts the library microservice
under pm2.
Runner Microservice (NestJS)
Run from servers/execution/runner/:
yarn test:unit and yarn test:int run the unit and integration tests
separately.
Logger Microservice (NestJS)
Run from servers/logger/:
DT Automation Library (TypeScript)
Run from lib/dt-automation/:
The package has no test script.
DTaaS CLI (Python)
Run from cli/:
The build step copies the shared code from lib/ into the package; the
tests cannot be collected without it.
GitLab Common Library (Python)
Run from lib/gitlab_common/:
Platform Services CLI (Python)
Run from deploy/services/cli/:
The CLI checks for root before it validates arguments, so non-root runs
need CI=true. The tests in tests/system_tests call docker.
Documentation Validation
Run from the repository root:
On Linux, to validate the full docs build including the PDF export:
Practical Tip
When changing several components, validate each package on its own first. Failures then stay local and are quicker to debug, and unrelated test errors do not get in the way.