Ad Hoc Testing of Distributed Systems

Tests are great! When used in your deployment workflows, you want them to be automated, running unattended.

They should have particular values defined as part of the testing environment, whether in QA, staging or any other environment. Automated tests such as these are the bedrock of a mature testing and deployment strategy.

In development and production, however, it’s useful to be able to select a test and run it with a value you specify at run time. Here are a couple of examples:

- I am a developer and I want to be able to run a test with different values as I am developing and testing my code to verify that it handles a range of inputs.

- I am an SRE, and things are not going well in production! I want to be able to run a “read-only” test such as one against a “GET” endpoint in production that I know should pass. I want to have it run with one or more particular values, such as the user id of a customer having a problem, and see the test results. I can also use this as a convenient way to see what the response of the API call is.

This is exactly what you’ll learn in this blog post. Tracetest now enables you to run ad hoc tests!


## Tracetest now Enables Ad Hoc Testing

[Tracetest](https://tracetest.io/) now has the ability for you to define and run manual, ad hoc tests! What!?

You haven’t heard of Tracetest? It is a modern testing tool built for the cloud-native world that utilizes the observability delivered by distributed tracing to allow you to build tests that can assert against both the response and the distributed trace. Since a trace has the full execution path and details about each microservice involved, you can [build complete system tests](https://thenewstack.io/trace-based-testing-for-a-distributed-world/) against your distributed application that are more powerful than you can with prior tools. It is also much quicker and easier to build these tests. So, back to this new, powerful capability. How can you define ad hoc tests in Tracetest? To do so, you define one or more variables in your test. These variables can be part of the trigger definition, or they can be part of a test spec. Once you have defined a variable, you then can either:

- Add an environment, defining within it the variables referenced. When you run this test with the environment selected, it will not prompt you for the value, automatically running the test based on the values defined in your environment.

- Do not select an environment, and run the test. Tracetest will prompt you for the values for the variable, allowing you to run it with different parameters as a manual, ad hoc test.

How do you define a variable in a test? Use this syntax to specify a variable:

```bash

${env:YOUR_VARIABLE_NAME}

```

For example, let's say I want to “GET” a particular entity in a test, a Pokemon in this case, but I want the test to be flexible and accept the value for the Pokemon ID from a variable. We will change the URL for the GET to have a variable where the Pokemon ID would normally be. In this case, we will call the variable ‘P_ID’. This is how you would define it when setting up the test:


## Build Your Own Ad Hoc, Distributed Trace-Based Tests

This new ability makes Tracetest much more useful for running ad hoc tests on demand. Ready to try Tracetest in your environment? Check out our [easy download](https://tracetest.io/download), then create some tests and define some variables in the trigger or in your test specifications.

Any [issues can be raised](https://github.com/kubeshop/tracetest/issues/new/choose) in Github, and you can communicate directly with the team [in Slack](https://dub.sh/tracetest-community). Open-source projects such as Tracetest depend on the input and support of the community and welcome your input and ideas. If you like our direction and what you are seeing from Tracetest - [give us a star](https://github.com/kubeshop/tracetest) on GitHub.