Activity/OpenTelemetry support

[TheAngryByrd]

👋 Would y'all be open to adding Activity/OpenTelemetry support in Expecto? I would usually wrap the tests in my own testCase but the main issue is it won't have the whole name since the test itself won't be a FlatTest.

This wouldn't be adding any dependencies as ActivitySource/Activity is already in .net itself. I think adding an ActivitySource to the ExpectoConfig and then using it in the execTestAsync would be the most straight forward approach.

Some resources to read:

• https://learn.microsoft.com/en-us/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs#activity
• https://www.jimmybogard.com/activitysource-and-listener-in-net-5/

[farlee2121]

First I want to make sure I'm understanding the underlying problem/motivations.
Could you elaborate on what problem you're facing and what the ideal outcome is?

[TheAngryByrd]

First I want to make sure I'm understanding the underlying problem/motivations. Could you elaborate on what problem you're facing and what the ideal outcome is?

Yeah absolutely. The underlying motivations are the ability to get determine failures during test runs to investigate issues. This doesn't come up as much in strictly unit tests but it much more useful for things like integration tests, where something could be failing in a number of subsystems. Specifically, in FsAutocomplete, it could be in Project Cracking, FSharp Compiler service, or some other subsystem of FsAutocomplete. Sometimes tests only fail in things like CI or in extreme parallelism where a singular focused test it will pass, and obtaining logs specific to those tests can be tricky.

This article https://www.honeycomb.io/blog/monitoring-unit-tests-opentelemetry might shine a bit more light on the subject.

[farlee2121]

If I'm understanding right, you want to add a trace or span to better group telemetry by test.
The reason you want to add it to the library instead of a custom extension (e.g. test fixture) is because you need access to the full test name.

If this is the case, I'm not opposed to the idea of adding open telemetry, but I also feel like access to the full test name is a more general problem that lots of extensions would want solved if we can solve it generally

[TheAngryByrd]

Yeah, there's a few other piece of info that would be "nice" to have as well, such as adding adding exception/TestOutcome information.

I can send a PR so we can discuss what it would look like. But yeah if there's better ways to expose the info so it's easier to create wrapper's I'm for it.

[farlee2121]

For future readers, the conversation continued in PR #497

The general approach was to map the test list with an open telemetry wrapper. This does have the downside that it doesn't centrally apply to tests discovered using reflection via [<Tests>].
This is also a challenge for methods like shuffle and filter