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.
All tagged testing
Shameless green: TDD in Go
Building software is easy when we’re guided by tests, because we can start with quick-and-dirty solutions, without worrying about whether the code is elegant and readable—yet. Let’s see how to use the TDD technique called “Shameless Green”.
Test names should be sentences
Tests communicate a lot of information, to readers, other developers, and even our future selves. Well-written tests focus on a single unit of behaviour that can be described in a brief sentence, and we can use that sentence as the name of the test.
Programming with confidence: TDD in Go
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.
Finding bugs with fuzzing
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.
Writing a Go fuzz target
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 tests in Go
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!
Random testing in Go
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.
The adapter pattern in Go
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.
From packages to commands
In Part 2 of a series about writing packages, not programs, we see how to test a package that prints to the terminal, and use the result to build our “hello, world” CLI tool.
Go’s best-kept secret: executable examples
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.
Error wrapping in Go
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.
Comparing Go error values
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.
Testing errors in Go
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?
Testing CLI tools in Go
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.
Test scripts in Go
Wouldn’t it be great if we could write tests for our Go CLI tools that are simple as shell scripts? The testscript package lets us do exactly that. Let’s take it for a spin.
Test-driven development with Go
What is test-driven development (TDD), and how does it work in Go? This friendly tutorial shows you how to build a new Go package from scratch, test-first, step by step. All you need is Go!
Introducing Test-Last Development (TLD)
Do you find writing tests hard? Especially writing them first? Don’t let smug Internet thought leaders tell you what to do. Instead, embrace the new software paradigm that lets you just do whatever comes easiest.
Ten commandments of Go
I spend a lot of time working with students to help them write clearer, better, and more useful Go programs, using a fairly small set of general principles, and here they are. The first is “be boring”, and I’ve tried to follow that advice.