Create environment variables to assert the same behavior across multiple environments (dev, staging, and production, for example)
Create test outputs by defining a variable based on the information contained in a particular span's attributes.
Run ad-hoc tests by using undefined variables to enable supplying variables at runtime.
Define test suites/transactions to chain tests together and use variables obtained from a test in a subsequent test. These variables can also be loaded from the environment.
This command will launch an install wizard that automatically installs Tracetest and a sample Pokeshop Demo app into either Docker or Kubernetes based on your selection.
Or, install Tracetest with Helm. The Tracetest Helm charts are located here.
The trace is the blueprint of your system under test. It shows all the steps the system has taken to execute the request.
Use this blueprint to define assertions in the Tracetest Web UI.
Add assertions on different services, checking return statuses, data, or even execution times of a system.
Run the tests.
Once the test is built, it can be run automatically as part of a build process. Every test has a trace attached, allowing you to immediately see what worked, and what did not, reducing the need to reproduce the problem to see the underlying issue.
📂 What does the test definition file look like?
The Tracetest test definition files are written in a simple YAML format. You can write them directly or build them graphically via the UI. Here is an example of a test which:
Executes POST against the pokemon/import endpoint.
Verifies that the HTTP blocks return a 200 status code.
Verifies all database calls execute in less than 50ms.
type: Test
spec:
id: 5dd03dda-fad2-49f0-b9d9-5143b746c1d0
name: DEMO Pokemon - Import - Import a Pokemon
description: "Import a pokemon"
# Configure how tracetest triggers the operation on your application
# triggers can be http, grpc, etc
trigger:
type: http
httpRequest:
method: POST
url: http://demo-pokemon-api.demo.svc.cluster.local/pokemon/import
headers:
- key: Content-Type
value: application/json
body: '{"id":52}'
# Definition of the test specs which is a combination of a selector
# and an assertion
specs:
# the selector defines which spans will be targeted by the assertions
selector: span[tracetest.span.type = "http"]
# the assertions define the checks to be run. In this case, all
# http spans will be checked for a status code = 200
- assertions:
- http.status_code = 200
# this next test ensures all the database spans execute in less
# than 50 ms
selector: span[tracetest.span.type = "database"]
- assertions:
- tracetest.span.duration < "50ms"
🤖 How to run an automated test?
Save a test definition file above as pokeshop_import.yaml. Use the CLI to run a test.
tracetest run test --file /path/to/pokeshop_import.yaml
Check out the CI/CD docs to learn more about test automation.
🧪 Tests
We strive to produce quality code and improve Tracetest rapidly and safely. Therefore, we have a full suite of both front-end and back-end tests. Cypress tests are running against the front-end code and (surprise, surprise) Tracetest against the back-end code. You can see the test runs here, and a blog post describing our testing pipelines here.