Opentelemetry-go: Introduce stretchr/testify test helper library

[tigrannajaryan]

http://github.com/stretchr/testify is a nice library for Go code that helps write cleaner tests. It will be great to introduce this to our codebase.

[freeformz]

FWIW: I'm -1 on testify, but I won't be grumbly about it if other's feel differently.

My personal testing preferences are: if's, cmp.Diff, and local helpers for anything more complex. Additionally I've seen testify stuff hide errors in the past.

[tigrannajaryan]

@freeformz can you expand on what situations you saw testify hide errors? I have been using it in opencensus-service and it is already in the codebase that we brought in. My experience with testify was positive so far and cutting the boilerplate of if cmp { log something } has been very useful in tests.

[freeformz]

@tigrannajaryan All of the instances I can think of have been in private repos, but I have seen assert.Equal() hide errors. Those were essentially tracked down to assert's use of interface{}
(PS: cmp.Diff suffers from this same issue, but so far I haven't been surprised by it).

FWIW: I find the ....

if tc.expected != got {
  t.Errorf("expected %q, got %q", tc.expected, got)
}

AND

if diff := cmp.Diff(tc.expected, got); diff != "" {
  t.Error(diff)
}

boilerplate much more consumable than assert.Equal() and friends. For tests, they hide too much for me.

But again and since this is a personal preference thing, I won't complain further (at least not now or for a while) if others vote in favor of testify

WRT opensensus-service, only the following packages use testify's assert package:

"github.com/census-instrumentation/opencensus-service/cmd/occollector/app/builder"
"github.com/census-instrumentation/opencensus-service/exporter/opencensusexporter"
"github.com/census-instrumentation/opencensus-service/internal/configv2"
"github.com/census-instrumentation/opencensus-service/processor/addattributesprocessor"
"github.com/census-instrumentation/opencensus-service/receiver/jaegerreceiver"
"github.com/census-instrumentation/opencensus-service/receiver/opencensusreceiver"

There are 37 other packages that do not.

[cstockton]

I am very much against using large frameworks for writing unit tests. Unit tests are not just for testing results, they also lock in your public API. Using a large unit tests abstraction that accepts interfaces everywhere means that type changes are possible without breaking unit tests.

If I can get an example of any test case that we feel a large testing framework is needed, I can provide potential idiomatic Go solutions instead. Just mention me and I'll be happy to help.

[rghetia]

There is consensus to use simple framework provided by Go itself.