Overview
A test execution environment is a sandboxed environment where Tusk runs the tests it generates. Think of it as a Docker container specifically configured for your project’s testing needs.Test execution environments are fully managed by Tusk. We handle:
- Infrastructure and resource allocation
- Initial configuration during automated setup
- Ongoing maintenance as your project evolves
How It Works
When Tusk generates tests for a PR, it:- Spins up an isolated sandbox using your test execution environment
- Checks out your code at the PR’s commit
- Runs setup scripts to install dependencies
- Uses test and lint scripts to ensure all generated tests are working and conforming to your codebase’s standards
- Reports results back to your PR
Configuration Components
Each test execution environment consists of several components that Tusk configures automatically during setup.Environment Definition
You’ll have either a Dockerfile or a Docker Compose configuration depending on your project’s needs. Dockerfile - For most projects where tests only need the application runtime and mock external services. Docker Compose - For projects where tests need real service dependencies (databases, Redis, etc.). Tusk analyzes your repository and CI configuration to automatically determine which approach is best for your project.Scripts
| Script | Purpose |
|---|---|
| Setup | Installs dependencies and prepares the environment |
| Test | Runs tests for a specific file |
| Lint | (Optional) Runs formatting/linting and build checks |
| Coverage | (Optional) Collects test coverage data |
Configuration Settings
| Setting | Description |
|---|---|
| Test Framework | The testing framework detected |
| App Directory | For monorepos, the subdirectory containing your service |
| Test File Regex | Pattern for matching test files in your codebase |
Viewing Your Configuration
To view an existing test execution environment:- Go to the Unit Tests page
- Click on your repository
- Select the Test Execution Environments tab
- Click on an environment, then select the Configuration tab
- The complete Dockerfile or Docker Compose file
- All setup, test, lint, and coverage scripts
- Environment variables (non-secret values only)
- Test file pattern and other settings
Updating Configuration
If you need to modify your test execution environment:- Navigate to the environment in the Tusk UI
- Click Update
- Describe what you’d like to change
- Tusk will update and re-verify the configuration
- Adding new system dependencies
- Changing test commands or flags
- Enabling coverage collection
- Adding support for new services (databases, caches)
- Fixing issues with environment setup
Tusk verifies updates by running your tests, so you’ll know immediately if the changes work.
Environment Variables
Test environments often need environment variables. Some examples include:- NPM tokens for private packages
- Database passwords or connection strings
- Third-party service credentials
Managing Environment Variables
- Go to Repository Settings > Environment Variables
- Click Add Variable
- Enter the key, value, and mark as “Secret” if sensitive
- Variables are automatically available in all test environments for that repo
When Tusk Asks for Variables
During setup or updates, Tusk may detect that environment variables are needed. You’ll see a prompt asking for specific variables with context about why they’re needed. You can:- Provide the values now to ensure setup succeeds on the first try
- Skip for now - setup continues and Tusk will ask again if tests fail due to missing variables
Multiple Environments (Monorepos)
For monorepos with multiple services, you can have separate test execution environments - one per service directory (e.g.,packages/api, packages/web). Each environment has its own Dockerfile and scripts, can use different test frameworks, and runs independently.
During repository analysis, Tusk identifies each testable directory and lets you set them up individually.