Tracetest 0.6 Release: gRPC, Postman and More

The OpenTelemetry project and the observability space in general are all about 3 primary signals: Traces, Metrics, and Logs. The Tracetest team is focused on providing the best open source trace-based testing tool, so we spend most of our time and energy thinking about Traces, Spans, and Assertions. We do, however, take a look at metrics from time to time. The entire team was very excited this week to see some key metrics pass a couple of thresholds - we just hit 150 stars on Github and have crossed the 1K commits mark, 1,018 to be precise! We love the excitement and interest in the project, and are thrilled to share the v0.6 release with you and discuss all the changes we have made.

Following the v0.5 release in early June, the Tracetest team looked at the areas we should focus on for the next release. We decided on 3 major areas:
- Test Creation
- Trace Visualization
- Improving Assertion Capabilities

## Test Creation Using gRPC & Postman Collections

The first step in defining a Tracetest trace-based test is to trigger a transaction against the system under test. This causes the system to process a transaction and, since you have your system instrumented with OpenTelemetry tracing, a full distributed trace of the system is captured. Tracetest then allows you to create assertions based on the results from the trace data.

The initial versions only supported REST calls to trigger the transaction, but we wanted the system to be more flexible and support other types of triggers.  We made a ton of progress in this area.  First, we revamped the creation of a test via the UI with a plugin concept for triggers, enabling us to add new triggering methods to the system. The flow is wizard based, where you first choose the type of test trigger and then enter the details.

Second, we added RPC as a triggering method. You select RPC, upload your proto file, select the method, provide other configuration info, and create your test. gRPC is used extensively in modern architectures and micro-services, so this will be a very useful trigger type when creating tests.

Third, we added the ability to create a test from a Postman Collection. Postman is used by development teams across the world and we wanted to make it easy for you to upload your Postman Collection file, optionally upload an environment file, select a test from the collection, and then create a test.

## OpenTelemetry Trace Visualization Enhancements

It seems that with every release we talk about ‘trace visualization enhancement’. Well… Rome was not built in a day, and we are not going to build a world class trace visualization viewer in a couple of releases.  We are passionate about this goal and remained focused on it in this release. 

We totally revamped the look of the graph view of the trace. It now shows the most important information about a span, including the execution time. We also synchronized this look and feel across other areas of the UI where we reference a span.

On the timeline view of the span, we changed not only the look but also the underlying JS component used, moving from [D3.js](https://d3js.org/) to [visx](https://airbnb.io/visx/). This change will help us to embed the functionality we want in the component, and working with a library built from the ground up for React will make development faster and cleaner.

An important part of Tracetest are the assertions and we have a whole section below dedicated to the work we did to enhance it. On the trace view, we added the ability to ‘step through’ the spans being targeted by an assertion. For example, if you have an assertion that is being applied across all RPC spans and select it, you will see a ‘1 of X total’ in the trace view. You can use the right and left arrows to cycle from one to another and see exactly which spans are targeted by your assertions.

And, speaking of assertions…

## Improving Trace-Based Testing Assertions

Being able to target the spans you intend to test and create checks for it as part of building an assertion is at the heart of Tracetest. In this release, we took a big step in exposing the power of our testing engine in the UI by embedding a [custom language code editor](https://kubeshop.io/blog/creating-a-custom-language-code-editor-using-react) for defining advanced selectors.  Before, you could opt to use the [advanced selector language](https://kubeshop.github.io/tracetest/advanced-selectors/) in the [YAML-based test definition files](https://kubeshop.github.io/tracetest/test-definition-file/), but there were capabilities in this language which the front end could not duplicate. By embracing the advanced selector language in the UI, all the power of the backend is enabled. This includes some critical capabilities:

- The ability to have both AND and OR in a selector, allowing you to specify groups of spans in one assertion.
- The ability to have a blank selector, which will select all spans in a trace. This is useful when you want to assert that the trace result has a certain number of spans or at least X spans. This is done using the newly added tracetest.selected_spans.count attribute. With it, you can trigger a failed test for an incomplete trace, i.e. too few spans in the result or even fail a test if the number of spans has increased, letting you know a flow has significantly been altered and you may want to revise or extend your test.
- And our favorite, the ability to specify an ancestor of a span. This allows you to precisely target a span that may exist multiple times in a flow by specifying its parent or other ancestor.

‍

## Testing Tracetest

Lastly, but importantly, the team put a lot of energy into creating tests for the Tracetest project. This has several benefits:

- We are using Tracetest to build our tests, so we see first hand what works, what doesn’t, what needs improvements, and what features need to be added.
- We are establishing a high baseline of test coverage for both the UI & backend. This will allow us to provide a high quality project while still being able to execute changes quickly and with confidence.

We wrote several articles directly related to our testing of Tracetest while working on the 0.6 release. They provide a good explanation on how we, and you, can utilize trace-based testing:
- [Integrating Tracetest with GitHub Actions in a CI pipeline](https://kubeshop.io/blog/integrating-tracetest-with-github-actions-in-a-ci-pipeline)

- [Detect & Fix Performance Issues Using Tracetest](https://kubeshop.io/blog/detect-fix-performance-issues-using-tracetest)
- [Integration Tests: Pros and Cons of Doubles vs. Trace-Based Testing](https://kubeshop.io/blog/integration-tests-pros-and-cons-of-doubles-vs-trace-based-testing)

## Next Steps for the Tracetest team 

First, a bit of planning next week. We are a distributed, 100% remote team, with team members in Europe & the Americas (Central, North, and South!). We do, however, know the value of bringing the team together to meet in person, do a bit of in person team building, and brainstorm on future releases. Next week, the entire team will meet in Cartagena, Colombia to plan our next few months and perhaps enjoy a dinner at [El Arsenal](https://www.elarsenaltherumbox.com/).

For upcoming releases, the team is planning support for variables and more backend datastores will be on the list, but let's see what the team decides. In the meantime, you can help us set direction by:

- [Downloading and installing Tracetest](https://github.com/kubeshop/tracetest)
- Use it! Create some tests. Add some assertions.
- And, then, give us feedback.

[Issues can be created 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 to make this an awesome tool.