go-vcr VS gomega

Mocking the http client using recorded responses; for example using dnaeon/go-vcr

For example I see go-vcr (note: not mine), but haven't taken time yet to evaluate it.

I've finally found some spare time and managed to work on go-vcr, fixed some long standing issues, refactored things here and there and was able to get a new version of the package.

Terraform providers are tested this way (separate cloud account w/ create/destroy) paired with VCR to record and replay the HTTP requests.

Let me introduce to you github.com/dnaeon/go-vcr.

dnaeon/go-vcr

Gomega is a Go library that allows you to make assertions. In our example, we check if what we got is null, not null, or equal to an exact value, but the gomega library is much richer than that.

Depends on the API and how much testing you need. You want to test your code, not the API's availability or correctness.

But it can be as easy as using a fake http library and mocking the responses, or using a httptest server: https://onsi.github.io/gomega/#ghttp-testing-http-clients

If the API is complicated and you have to write your own fake server, that might not make sense for small projects.

If we do the count, we gather that subtest appear to solve five out of the six problems we identified with the assert library. At this point though, it's important to note that at the time when the assert package was designed, the sub-test feature in Go did not yet exist. Therefore it would have been impossible for that library to embed it into it's design. This is also true for when Gomega and Ginko where designed. If these test frameworks where created now, then most likely some parts of their design would have been done differently. What I am trying to say is that with even the slightest change in the Go language and standard library, completely new ways of designing programs become possible. Especially for new packages without any legacy use-cases to consider. And this brings us to generics.