undefined | Better HN

0 pointssethammons3y ago0 comments

The standard testing package for the win, and many pull in a light weight assertion library like Testify.

I love testing in Go (and _loath_ testing in Ruby). Our unit and integration tests are mostly great. Tests are just code. No DSL or special anything; just normal code. My favorite test that showed me the light: it would spin up several smtp servers (the system under test), like a dozen or more, get the SMTP conversation to different points and wait for timeouts and ensure that everything behaved. The test ran in under 10ms.

We have tests that ensure logs happened, metrics emitted, timeouts honored, graceful shutdowns work, and error paths are easily validated with test fakes that return canned errors (no mocks). I love testing in Go.

0 comments

3 comments · 1 top-level

xwowsersx3y ago· 2 in thread

Nice, thanks for the reply. Our Python tests run incredibly slowly. Having fast tests makes such a big difference. It can be really demoralizing waiting for a bunch of tests to finish. In general, I'm incredibly excited for how fast Go is, especially compared to Python. I had almost forgotten what fast feels like.

t435623y ago

With python you could choose to use Pypy and make it work for your system - that might speed things up.

Alternatively, you could use smoketests. In my last largish project we grouped the tests into a short run and long run group. This allowed us to develop code and do a set of short tests in a fairly quick cycle and then before merging to the master branch we would do more comprehensive tests or let the CI system do it.

FWIW I got more joy from python by a long way but go isn't that awful except when you're trying to fork a github module to make it do something different.

xwowsersx3y ago

Oh ya know, I never did consider PyPy. Is it significantly faster than standard CPython? I'm going to look into trying it out. Would be amazing if we could easily get performance improvements with it.

Also, your idea about having a smaller set of quick running tests and then separate smoke tests is actually a great idea. What we've really done in many of the cases where we should have a unit tests, is essentially to write integration tests. Not quite end to end but pretty close and that's where a lot of the slowness comes from.

Appreciate the reply!

j / k navigate · click thread line to collapse