FRESH

Hacker News

Scaling Go Testing with Contract and Scenario Mocks

42 points by preetamjinka

by aranw

2 subcomments

The problem with mocks is that they test your assumptions, not reality...
When you mock a CRM client to return one account, you're assuming it always returns one account, that IDs have a particular format, that there's no pagination, that all fields are populated. Each assumption is a place where production could behave differently whilst your tests stay green
Your contract tests use cached JSON fixtures. Salesforce changes a field type, your contract test still passes (old fixture), your mocks return the wrong type, production breaks. You've now got three test layers (contract, mock scenarios, E2E) where two can lie to you. All your contract and mock tests won't save you. Production will still go down
I have zero confidence in these types of tests. Integration tests and E2E tests against real infrastructure give me actual confidence. They're slower, but they tell you the truth. Want to test rate limiting? Use real rate limits. Want to test missing data? Delete the data.
Slow tests that tell the truth beat fast tests that lie. That said, fast tests are valuable for developer productivity. The trade-off is whether you want speed or confidence

by SPascareli13

5 subcomments

I really dislike this idea of testing in go: only ever use an interface, never the real implementation + mockgen the mocks based on this interface + use the mocks to assert that a function is called, with exactly this parameters and in this exact order.
I find this types of tests incredibly coupled with the implementation, since any chance require you to chance your interfaces + mocks + tests, also very brittle and many times it ends up not even testing the thing that actually matters.
I try to make integration test whenever possible now, even if they are costly I find that the flexibility of being able to change my implementation and not break a thousand tests for no reason much better to work with.

by kardianos

3 subcomments

My DB heavy app, when I run a Go unit test, it spins up a DB instance, populates it, runs the tests, and drops the DB. Never ever any mocks. The best part about unit tests isn't testing the Go code. It is testing the SQL.
Yes, it takes longer to run your tests. So be it.

by fireflash38

0 subcomment

I'm of the opinion that mocks should be provided by the thing that you're mocking. That is, if you are wanting to mock out a service, the mock should be owned by the service that is being mocked.
And then it should be part of that service's test suite, to verify it's own mock.
You update your service? Then you must update the mock.
I guess that's more of a fake, but the naming doesn't matter as much as the behavior.

by teeray

2 subcomments

> Mocks are static, but reality evolves.
I learned “test your mocks” long ago from Sandi Metz, and that advice has paid off well for me. Have some set of behavioral conformance tests for the kind of thing you expect (e.g. any database worth its salt should be able write and read back the same record). Then stick your mock right under that same battery of tests alongside your implementation(s). If either deviate from the behavior you depend on, you’ll know about it.

by gethly

0 subcomment

Testing in Go is great, for unit testing. But anything above that should be done manually. "Mocking" never made sense to me and I never used it in my entire life. If I want to test a database/repository, I will spin up a real database with real data and data persistence instead of relying on in-memory storage and try to abstract away things that make no sense to do in the real world, as we're not living in a theoretical world of interfaces and adapters and whatnot.

by isuckatcoding

2 subcomments

Wow a full post about contract testing without mentioning pact
https://pactflow.io/