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
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.
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”.
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.
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.
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.
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.
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.
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 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.
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.
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!
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.
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.