Things to consider when testing in Go

How do you know if your codebase has the appropriate testing strategy? Do you shoot for 100% code coverage, or is that missing the point? Do your unit tests give you the peace of mind they should or do you have flaky tests that occasionally break for some reason? Do you write tests before or after program code?

The right testing strategy gives you the confidence you need to make bold changes in your codebase, and gives you the best chance of your code having a long, well-maintained life.

Ensuring your team is appropriately testing their code can be a big challenge — and because there are no right or wrong answers, it can be tough to get right.

At dotGo in Paris, 2017 I spoke about The Art of Testing, and received a lot of great feedback, as well as some strange specific questions which demonstrated to me that testing really is more of an art than a science.

I also founded Testify, Is, Silk and Moq testing helpers for Go.

Here’s a high level look at some things to consider:

The up-front cost of building something is tiny compared to the amount of time we spend maintaining it over the years, especially for successful projects. Good tests help us write maintainable code.

Tests should not be an afterthought — they’re a vital piece of the project.

It’s easy to get obsessed with testing everything, but some things don’t need testing.

Tests are written in Go, so you can use the language to build the tools you need to improve your tests.

A real example of a test HTTP server, including a cleanup function to tidy up afterwards.

Readability is a vital part of maintainability, the is package brings that readability.

Mocking out interfaces is a great way to write isolated tests without touching third-party systems every time you run them. But you don’t need to mock everything :)

Private workshop for your team

Simple, obvious tests are the best — and they’re possible even if they’re testing complicated things

I’m going to be doing co-located or remote workshop sessions starting in January 2018, where I’ll sit with your team and go over their current testing situation. With fresh eyes, we’ll analyse the effectiveness of the tests and look at ways they might be improved. We’ll also talk about testing philosophies and how they might be applied in each specific case to power up your testing strategy. With real examples from your actual project, we’ll try a few different approaches and look at the pros and cons of each; from fine grained unit tests, to high level end-to-end tests, and beyond.

If you’re interested, ping me on Twitter or drop me an email to learn more and we’ll have a discussion about your needs. If you know somebody that might be interested, it would be great if you could forward them this post.

I’ve written a lot about testing in the past, so you can get a taste of the style by checking out these posts:

• 5 simple tips and tricks for writing unit tests (over 112,000 reads)
• Read more about Silk API testing, and mocking interfaces in Go
• More posts about Go