You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 31, 2023. It is now read-only.
First of all, I want to let you know that I'm new to OpenCensus so maybe I'm taking a bad approach :)
I'm trying to add OpenCensus stats as part of instrumentation to one of the libraries I maintain.
I started getting familiar with some of the concepts and reading internal library code so I could create a OpenCensus Recorder on Kooper.
The problem is that I would like to inject an OpenCensus "registry", "recorder" or similar (the name doesn't matter) object, and (I think that) OpenCensus works at global level
I've checked the tests of the worker and they work at the same package as the worker itself (go.opencensus.io/stats/view) so they can create new worker instances without problem, but outside the library that's not possible.
So, in other words, I can't decouple my code correctly, inject the dependencies and make each test to be idempotent and independent without small hacks like reset functions. Appart from this, working in global context I can't make my tests run in parallel.
I'm missing something or there is an established approach when using and testing opencensus-go in other applications?
Is there out there any Go application or library using OpenCensus and tested so I can read the code as an example? I did not found.
Thank you for your time and OSS contributions!
The text was updated successfully, but these errors were encountered:
Yeah I have had the same complaint writing tests. I don't like all the global state we use, and there's a lot. We try to hide it all internally. Of course, this makes it very difficult to write tests against the library.
I have a few suggestions:
OpenCensus is really not ready to be depended on by other libraries without vendoring, since the APIs are changing rapidly. So in this case, you might want to wrap OpenCensus and have your wrapper be non-global and mock it out for testing.
Create new measures and view for every test (gets very ugly fast)
Help us make it better somehow - TBH I don't know what we should really do here. On the one hand I really don't want to require people to pass around a Recorder object. But maybe that's not so bad. I'm intrigued by the possibility of overriding the recording with a Context value, but that sounds like it might be an abuse of context.Context.
Hi!
First of all, I want to let you know that I'm new to OpenCensus so maybe I'm taking a bad approach :)
I'm trying to add OpenCensus
stats
as part of instrumentation to one of the libraries I maintain.I started getting familiar with some of the concepts and reading internal library code so I could create a OpenCensus
Recorder
on Kooper.The problem is that I would like to inject an OpenCensus "registry", "recorder" or similar (the name doesn't matter) object, and (I think that) OpenCensus works at global level
opencensus-go/stats/internal/record.go
Line 12 in 904befa
opencensus-go/stats/view/worker.go
Lines 28 to 32 in 904befa
opencensus-go/stats/view/worker.go
Lines 156 to 166 in 904befa
I've checked the tests of the worker and they work at the same package as the worker itself (
go.opencensus.io/stats/view
) so they can create new worker instances without problem, but outside the library that's not possible.opencensus-go/stats/view/worker_test.go
Lines 579 to 583 in 30bf88b
So, in other words, I can't decouple my code correctly, inject the dependencies and make each test to be idempotent and independent without small hacks like reset functions. Appart from this, working in global context I can't make my tests run in parallel.
I'm missing something or there is an established approach when using and testing opencensus-go in other applications?
Is there out there any Go application or library using OpenCensus and tested so I can read the code as an example? I did not found.
Thank you for your time and OSS contributions!
The text was updated successfully, but these errors were encountered: