Thou shalt not suffer a flaky test to live, because it’s annoying, counterproductive, and dangerous: one day it might fail for real, and you won’t notice. Here’s what to do.
All tagged the power of go tests
Thou shalt not suffer a flaky test to live, because it’s annoying, counterproductive, and dangerous: one day it might fail for real, and you won’t notice. Here’s what to do.
What are the best Go books this year? Read my (relatively) unbiased recommendations for the Go books you should absolutely buy and read right now, whether you’re a beginner or expert Gopher.
Tests are great, provided they actually test something. But are your tests too optimistic (assuming the code already works), or too persnickety (testing the irrelevant)?
How do you rescue a legacy codebase that has no tests? Let's look at some techniques for clawing your way back to maintainability, one test at a time.
There’s an easy, pleasant, and reliable way to build software in Go, guided by tests. Let’s find out what it’s like to program with confidence, in the first part of this TDD tutorial series.
In the thrilling conclusion to our fuzz testing series, we’ll use Go’s fuzzer to find a real bug in our code, and also to verify the fix.
Let’s continue our exploration of fuzz testing in Go with a look at how to write a fuzz target for a (nearly) realistic function. This time we’ll try to detect a common kind of bug involving a confusion between runes and bytes.
Fuzz testing is Go’s clever way of generating new test inputs that you didn’t think of—and that may flush out some hidden bugs. Stand by for things to get a little fuzzy!
Choosing good test cases for our Go programs can be a bit hit-and-miss. What if we could automate that process? Let’s talk about randomisation, property-based testing, and Go’s built-in fuzz testing feature.
How do you test a database without a database? Don't worry, this isn't one of those Zen puzzles. I have something more practical, but equally enlightening, in mind. Let’s use the adapter pattern to solve the riddle.
Go has a great standard library. What if we think about our work not merely as building one-off programs, but instead contributing packages to the universal Go library?
Did you know that Go lets us provide executable code examples as part of our documentation? It’s pretty neat. Let’s take a tour of this useful feature and see how it works.
Distinguishing between specific error values and types is easy in Go, thanks to the (relatively) new errors.Is and errors.As functions. Let’s talk about what they do, when and how to use them, and how to know which one is appropriate.
Wouldn't it be nice if we could run test scripts directly from the command line? The standalone testscript tool does exactly that. Let’s see how to use it to create simple, self-contained issue repros.
Usually what matters about an error is that it’s not nil, but what if we want to know whether it’s some specific error value? For example, in a test? Let’s look at some of the right and wrong ways to do that.
Continuing our series on the testscript package, we look at some advanced techniques in test scripts such as conditions, concurrency, and managing environment variables.
How should we test errors in Go? And how does the need for this testing influence the way we construct, handle, and pass around errors within our Golang programs?
The txtar format is an ingenious way to supply arbitrary files and folder structures to test scripts. We’ll also learn about file management, simulating standard input, and breaking up scripts into phases.
The testscript package gives us an easy way to test the behaviour of a Go CLI tool, by executing it as an independent binary. Let’s see how.
If you’re a BIT student, are you ready for your green belt test? If you’re studying independently, check your Go skills and see whether you’d pass this demanding certification.