The goal right now is not to get the perfect answer but to pass the test. We’ll make our sacrifice at the altar of truth and beauty later. —Kent Beck, “Test-Driven Development by Example”
This is the second in a three-part series, extracted from my book The Power of Go: Tests, about test-driven development (TDD) in Go—in other words, building software in Go, guided by tests.
In Part 1, we started writing a retro text adventure in Go, guided by tests. The first test we wrote was for a function ListItems, which shows the player what items are present in their current location:
To validate this test, we deliberately wrote a buggy version of ListItems that always just returns the empty string. This should fail any self-respecting test, and so it does. Now let’s see if we can make it pass.
I really didn’t think too hard about this, and I’m sure it shows. That’s all right, because we’re not aiming to produce elegant, readable, or efficient code at this stage. Trying to write code from scratch that’s both correct and elegant is pretty hard. Let’s not stack the odds against ourselves by trying to multi-task here.