Tracetest v0.8: Chain Tests & Environment Vars

[Tracetest](https://tracetest.io/) is excited to announce v0.8!

Haven't heard of Tracetest yet? Tracetest is an [open-source project](https://github.com/kubeshop/tracetest) that enables you to write integration, system, and E2E tests against your distributed or microservice-based application. It uses the observability you enabled by implementing a distributed tracing solution to empower a totally new, modern way of testing – [Trace-Based Testing](https://thenewstack.io/trace-based-testing-the-next-step-in-observability/).

It only takes 5 minutes to configure Tracetest to be able to send a triggering transaction to your distributed app and tell it how to get traces from your existing OpenTelemetry based tracing solution. No need to change your code or existing tracing solution!

> In early December we hosted a [livestream webinar](https://www.youtube.com/watch?v=mp7f4RVi97g) showcasing transactions and environments from the v0.8 release of Tracetest!

‍

## Testing Microservices Requires Environments, Variables and Test Chaining

Testing of distributed applications happens across many environments and can involve several tests chained together to verify a complete flow through a system. The previous sentence contains an obvious statement to anyone who has written tests across multiple microservices.

When developing an entirely new approach to testing distributed applications from scratch, you start small with a core set of features and expand. This is what we did with Tracetest - we enabled it to run trace-based tests and released the initial capability this summer. We then built tests for Tracetest using Tracetest. And it was… hard!

As you can imagine, without a native capability to pass variables from one test to another, we had to rely on bash scripts, duct tape, and various forms of magic to string tests together.

Sebastian, one of our back-end engineers created the first system tests against Tracetest using Tracetest. He referred to the work of chaining without a native chaining capability as ‘bull excrement’. Loved the trace-based tests, hated the duct tape.

We were not the only ones to notice the gap - Mark Watson filed a couple Github issues. One asked us to ‘[Provide a mechanism to make API calls in sequence](https://github.com/kubeshop/tracetest/issues/949)’ and another referenced the need for [variables in the trigger](https://github.com/kubeshop/tracetest/issues/948) of a test.

The team got busy, and we’re excited to announce the v0.8 release of Tracetest! Let's discuss the major enhancements.

## Test Environments and Environment Variables

Tracetest now allows you to define various environments, such as local, dev, test, QA or prod. Each environment can have variables associated with it. Here’s an example:

You can then utilize both the environment and the variables when running tests. Define a test trigger using the variables with this syntax:

‍

With this capability, you can have one test that you can run across multiple environments without altering it… one less roll of duct tape needed!

## Chaining Trace-Based Tests Together

Adding variables into Tracetest formed the basis of chaining tests together and passing variables between them.

‍

- Variables can be defined in a test based on any of the attributes contained in any span.

- You can use the new [‘expressions’](https://docs.tracetest.io/concepts/expressions) syntax to alter values stored from attributes. An example would be accessing a particular field from an attribute containing a JSON response with syntax such as:

- Tests can utilize variables defined in prior tests (or itself!)

- Tests can be chained together as ‘transactions’. A transaction is defined and then executed much like a test, but running one transaction results in all the chained tests executing in sequence.

- A transaction fails if the response to the trigger of any of the tests fails.

Let's look at a scenario so we can understand how these concepts come together. In this scenario, we want to ensure that the ‘import Pokemon’ API works, and that importing one Pokemon actually increases the total number of Pokemon. We will end up having four tests chained together:

Let’s build the four tests that will be involved in this chained transaction.

## Building the Four Tests

First, we will get the total number of Pokemon from a ‘List’ test, and set an output variable. Second, we will do an import. Third, we will do another ‘List’ and make sure the number of Pokemon has increased. Lastly, we will delete the Pokemon to ‘clean up’.

Videos, or animated gifs in this case, are worth several thousand words, so let's see a couple of examples. First, let's create a variable based on the number of Pokemon returned by the first ‘List’ api call. This value appears in our trace in the ‘count pokeshop.pokemon’ span:

You can see that we select the span and the attribute, create an output variable, name it, and add it as an output. Our plan is to use that variable, the POKEMON_COUNT, in the third test as part of our chained transaction to verify that the count has increased after importing one new Pokemon.

Next, we define the ‘import’ test. Rather than looking at how it was created in the UI, let's view the test definition for the completed test:

Notice that we are using variables in several places in this test. The trigger uses them so this one test can run in multiple environments with this line:

We are also setting a variable, `IMPORTED_POKEMON_NAME`, in this output statement:

We verify that the value for the Pokemon name in our database insert is correct by comparing it to the just created variable:

‍

‍

Now, let's use the variable captured in our first test, POKEMON_COUNT, in the third test, creating a test spec that checks if the IMPORT in the second test increases the number of Pokemon. This assertion uses another capability added in this release, the ability to put an expression in your assertions or when you define a output variable (see [expressions](https://docs.tracetest.io/concepts/expressions)):

As you can see, we look at the DB result in the ‘count pokeshop.pokemon’ span and compare it to the original count original Pokemon count + 1.

Finally, we build a ‘Delete’ test to remove the added Pokemon to clean up. Now, it is time to chain these 4 tests together in a transaction.

### Chaining Tests to Enable Integration Tests

Let’s see how we chain the four tests together. To do this, we return to the Tracetest home page and create a transaction, selecting each of the four tests:

As you can see, we added each of the four tests to the transaction. You can adjust the order of the tests to achieve the logic flow you desire. When you save the transaction, it runs and shows you the execution results.

### Tying it All Together… Literally!

This release makes Tracetest much more useful testing complex chained scenarios in multiple environments. Ready to try Tracetest in your environment? Check out our [easy download](https://tracetest.io/download), then create some tests and chain them together.

Any issues can be [raised in Github](https://github.com/kubeshop/tracetest/issues/new/choose), 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 we need YOUR involvement! If you like our direction and what you are seeing from Tracetest - give us a [star on Github](https://github.com/kubeshop/tracetest).