-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integrate go exporter metric tests with mock metric api #67
Integrate go exporter metric tests with mock metric api #67
Conversation
f9f117a
to
9edb0b1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs some cleanup, otherwise LGTM.
exporter/metric/metric_test.go
Outdated
@@ -39,14 +40,20 @@ var ( | |||
) | |||
|
|||
func TestDescToMetricType(t *testing.T) { | |||
cloudMock := cloudmock.NewCloudMock() | |||
client := cloudMock.MetricServiceClient |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is different from the approach in #66 where []option.ClientOption{option.WithGRPCConn(mock.ClientConn())}
is used instead.
Shall we use the same approach in both PRs for consistency (whichever is preferrable)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too sure about the usability of the approach in #66 here since the metric exporters here are defined literally by their respective structs and not by using the newMetricExporter
function defined here.
Seems to me there is a way to proceed, one involving reverting the changes to newMetricExporter
and passing in the correct clientOptions to direct requests to our mock api library. After looking closer, it seems newMetricExporter is the more "commerical" method of creating an exporter where one would actually want to connect to the google cloud instance instead of our mock api. Correct me if I'm misunderstanding, but I shouldn't have touched that file entirely.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mocking should be still as close to the actual code being used as possible, so it's preferable to use constructor functions over directly creating structs when possible.
If I understand correctly, using newMetricExporter
will increase the code coverage in tests, and will test the actual code executed when the metric exporter is being initialized in
me, err := newMetricExporter(&o) |
It's fine to merge the change as is, and then you may consider creating another PR switching to newMetricExporter
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, thanks a lot.
2f9dc1e
to
4e43654
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please revert changes in newMetricExporter
and invoke it with clientOpts using mock client in the tests instead (see comments).
5afe521
to
4eaed39
Compare
4eaed39
to
0a89df6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the confusion, but seems like adding mock to existing test is useless.
If you want to test the exporter with a mock server, you need to add new integration tests instead, which will be invoking the ExportMetrics
function
opentelemetry-operations-go/exporter/metric/metric.go
Lines 173 to 174 in 4866baa
// ExportMetrics exports OpenTelemetry Metrics to Google Cloud Monitoring. | |
func (me *metricExporter) ExportMetrics(ctx context.Context, cps export.CheckpointSet) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The direction looks good now, just a few more comments
// Register counter value | ||
counter := metric.Must(meter).NewInt64Counter("counter-a") | ||
clabels := []kv.KeyValue{kv.Key("key").String("value")} | ||
counter.Add(ctx, 100, clabels...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be nice to add a function for metrics similar to GetNumSpans() to be able to validate that the correct data appeared on the other end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, you may add another test which will construct the exporter via
opentelemetry-operations-go/exporter/metric/cloudmonitoring.go
Lines 49 to 50 in 4866baa
// NewRawExporter creates a new Exporter thats implements metric.Exporter. | |
func NewRawExporter(opts ...Option) (*Exporter, error) { |
func (me *metricExporter) ExportMetrics(ctx context.Context, cps export.CheckpointSet) error { |
adef7c9
to
4e6825b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@james-bebbington do you want to have a look before I merge it?
exporter/metric/metric_test.go
Outdated
@@ -20,15 +20,20 @@ import ( | |||
"reflect" | |||
"testing" | |||
|
|||
"github.com/googleinterns/cloud-operations-api-mock/cloudmock" | |||
"github.com/stretchr/testify/assert" | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: these imports should be together with the one below (i.e. no empty line)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surprising that the linter didn't pick this up. Maybe we need to add some more CI steps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Happy for you to merge
4e6825b
to
517aa5d
Compare
As described in the proposal, we want to integrate those writing exporters with our mock api instead having to call the google cloud libraries directly. In short, I simply replaced the current client calls with calls to our mock client.