Skip to content
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

Merged

Conversation

mabdi3
Copy link
Contributor

@mabdi3 mabdi3 commented Jul 14, 2020

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.

@mabdi3 mabdi3 marked this pull request as draft July 14, 2020 21:58
@mabdi3 mabdi3 force-pushed the mabdi3/mock-metric-integration branch 2 times, most recently from f9f117a to 9edb0b1 Compare July 15, 2020 19:12
Copy link
Contributor

@nilebox nilebox left a 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.

@@ -39,14 +40,20 @@ var (
)

func TestDescToMetricType(t *testing.T) {
cloudMock := cloudmock.NewCloudMock()
client := cloudMock.MetricServiceClient
Copy link
Contributor

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)?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

exporter/metric/metric_test.go Show resolved Hide resolved
exporter/metric/metric_test.go Outdated Show resolved Hide resolved
exporter/metric/metric_test.go Outdated Show resolved Hide resolved
exporter/metric/metric_test.go Outdated Show resolved Hide resolved
exporter/metric/metric.go Outdated Show resolved Hide resolved
exporter/metric/metric_test.go Outdated Show resolved Hide resolved
@mabdi3 mabdi3 force-pushed the mabdi3/mock-metric-integration branch 3 times, most recently from 2f9dc1e to 4e43654 Compare July 20, 2020 22:49
Copy link
Contributor

@nilebox nilebox left a 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).

exporter/metric/metric.go Outdated Show resolved Hide resolved
@mabdi3 mabdi3 force-pushed the mabdi3/mock-metric-integration branch 3 times, most recently from 5afe521 to 4eaed39 Compare July 21, 2020 00:23
@mabdi3 mabdi3 force-pushed the mabdi3/mock-metric-integration branch from 4eaed39 to 0a89df6 Compare July 21, 2020 00:25
Copy link
Contributor

@nilebox nilebox left a 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

// ExportMetrics exports OpenTelemetry Metrics to Google Cloud Monitoring.
func (me *metricExporter) ExportMetrics(ctx context.Context, cps export.CheckpointSet) error {
, which should invoke the gRPC client and then you can validate the behavior using a mock.

exporter/metric/metric_test.go Show resolved Hide resolved
exporter/metric/metric_test.go Outdated Show resolved Hide resolved
Copy link
Contributor

@nilebox nilebox left a 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...)
Copy link
Contributor

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.

Copy link
Contributor

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

// NewRawExporter creates a new Exporter thats implements metric.Exporter.
func NewRawExporter(opts ...Option) (*Exporter, error) {
and invoke
func (me *metricExporter) ExportMetrics(ctx context.Context, cps export.CheckpointSet) error {
directly and assert that there is no error

exporter/metric/metric_test.go Outdated Show resolved Hide resolved
@mabdi3 mabdi3 force-pushed the mabdi3/mock-metric-integration branch 2 times, most recently from adef7c9 to 4e6825b Compare July 21, 2020 22:13
@nilebox nilebox marked this pull request as ready for review July 22, 2020 04:10
Copy link
Contributor

@nilebox nilebox left a 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?

@@ -20,15 +20,20 @@ import (
"reflect"
"testing"

"github.com/googleinterns/cloud-operations-api-mock/cloudmock"
"github.com/stretchr/testify/assert"

Copy link
Contributor

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)

Copy link
Contributor

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

Copy link
Contributor

@james-bebbington james-bebbington left a 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

@mabdi3 mabdi3 force-pushed the mabdi3/mock-metric-integration branch from 4e6825b to 517aa5d Compare July 22, 2020 19:09
@nilebox nilebox merged commit ce9a184 into GoogleCloudPlatform:master Jul 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants