3 ms·

How do you write your tests? I love go, but when it comes to testing I'm torn between having a more standardized setup with BDD tests (but worse ergonomics), or

How do you write your tests? I love go, but when it comes to testing I'm torn between having a more standardized setup with BDD tests (but worse ergonomics), or completely free-form tests with just a simple assertion library (but better ergonomics).

drakonka 5y ago
There isn't really any set testing methodology I am married to, other than writing tests for behaviour I want to ensure (both at function and public API level). Go makes that really intuitive. I usually write a test right after implementing the first version of a struct. I make use of both private unit tests in the same package alongside the implementation and public API integration tests in a separate test package. I don't make it a rule to test every single function or anything, but Go seems to make it easy to end up with pretty high coverage and fairly low maintenance overhead. I make pretty heavy use of mocks and like how easy it is to mock external API calls in Go by either wrapping an external call in a mockable interface or spinning up a local server with `httptest`. I also love how quick it is to write a couple of benchmark tests to get a rough idea of perf tradeoffs between approaches. I usually try to keep tests small, but I do like testing more end to end and inter-package flows as well. At some point large tests do get brittle and reliability on CI is key so I try to stay away from convoluted test paths, but it's been pleasantly doable to write reliable tests even for larger flows with Go. When I worked on an auth service we had tests going through full oauth failure and success flows and those got pretty big (eg imagine an end to end PKCE auth code grant test that also has to communicate with an additional external provider). For these we had separate tests at the storage level, and mocked storage (or used a test memstore where relevant) at the auth handler level. I like `testify` for assertions, `gomock` for mocking, `spannertest` for spanner, and `miniredis` for redis testing.
- happens 5y ago
  Thanks, that's very insightful. I feel like especially in larger projects, going for a monorepo approach where the integration tests are just another package that runs on the entire repo makes what you're doing very powerful.

drakonka 5y ago

There isn't really any set testing methodology I am married to, other than writing tests for behaviour I want to ensure (both at function and public API level). Go makes that really intuitive. I usually write a test right after implementing the first version of a struct. I make use of both private unit tests in the same package alongside the implementation and public API integration tests in a separate test package. I don't make it a rule to test every single function or anything, but Go seems to make it easy to end up with pretty high coverage and fairly low maintenance overhead. I make pretty heavy use of mocks and like how easy it is to mock external API calls in Go by either wrapping an external call in a mockable interface or spinning up a local server with `httptest`. I also love how quick it is to write a couple of benchmark tests to get a rough idea of perf tradeoffs between approaches. I usually try to keep tests small, but I do like testing more end to end and inter-package flows as well. At some point large tests do get brittle and reliability on CI is key so I try to stay away from convoluted test paths, but it's been pleasantly doable to write reliable tests even for larger flows with Go. When I worked on an auth service we had tests going through full oauth failure and success flows and those got pretty big (eg imagine an end to end PKCE auth code grant test that also has to communicate with an additional external provider). For these we had separate tests at the storage level, and mocked storage (or used a test memstore where relevant) at the auth handler level. I like `testify` for assertions, `gomock` for mocking, `spannertest` for spanner, and `miniredis` for redis testing.

happens 5y ago
Thanks, that's very insightful. I feel like especially in larger projects, going for a monorepo approach where the integration tests are just another package that runs on the entire repo makes what you're doing very powerful.