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.
Here’s a high level look at some things to consider:
Private workshop for your team
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.