When your life depends on computer code, how reliable do you want that code to be?
How is the computer code for an airplane, an MRI or a self driving car tested?
If you make your living programming, HOLD I recommend you take a day or two to work through this book by Kent Beck, “Test Driven Development, by example”
G’day! Welcome my friend to WTK, the “What to know” show. I’m your host Peter, Whelan
I’ve hired, trained and managed dozens of programmers.
Not to be impolite, but if you’re delivering code to me, I expect you to have tested it.
Test driven development is A way of developing clean code that works.
Published in 2003, this book laid the foundation for writing your tests before writing the code to be tested.
You may be thinking, why would I write the test before I write the code? I ask that you withhold judgement until you’ve worked through this book. Give it a chance and then decide for yourself.
I’ve researched TDD, tried it and studies have concluded that the effort is worth it.
Overall, TDD can save you a lot of time debugging. It improves your approach to writing code.
If you have tried TDD without reading this book, you may find that it’s not what you think it is.
As you know, there’s a wide range of opinions on testing.
I think that’s because there’s a wide range of uses for software.
The use case matters. Some code isn’t worth testing.
Some code can kill you. Think of self driving cars. They operate at over 100 teraflops, that’s 100 trillion operations a second and contain over 100 million lines of code.
I expect that to be tested with a wide range of uses. Simulate a kid laying in the street, drunk drivers in the wrong lane, red light runners. I want billions of miles simulated based on every kind of real life condition.
I have worked with people who insisted that it’s the customers job to test.
They opposed in-house testing, choosing to fix only the bugs that the customer reported.
The way they saw it, fixing bugs that the end user never noticed is a waste of time and money.
When the product failed, it was aggravating, but no one was injured. TDD is NOT welcome in that kind of environment.
Of course, everyone was in favour of automating tests. Once a human being has reported a problem, automated tests ensure that particular bug is never seen by a client again.
Test Driven Development is A way of writing code that structures all the activities of development.
You start with a requirement and you think “How am I going to test this feature?”
You write the test first. As you know, if you leave testing until after the code is written, you may never get around to it.
When you have automated unit tests, you can refactor with confidence. Unit tests are written by programmers, for programmers.
Kent walks you through a program to handle two currencies of money, taking tiny steps. It’s straightforward and sometimes humorous. You write the code along with him. He explains his thought process and that’s important.
It’s the mental state that Test Driven Development puts you in that you want to get out of this, focusing on one thing at a time.
If you are programming in pairs, extreme programming, you can write the failing test and your partner can implement the code to get it to work.
Seeing the test in code makes it clear what your partner is trying to do.
Working through the examples, you will get the TDD cycle into your head. You have to do the coding, the hands on work, to get the gist of it.
Writing tests first influences how you think about the code. There ARE a couple of places where I see programmers go wrong with Test Driven Development.
First, what’s the unit that’s being tested? It’s a unit of behaviour for a requirement.
Sometimes unit testing becomes class testing. The unit under test isn’t necessarily a single class.
You’re testing the behaviour of features, not the implementation.
Behaviour Driven Development, BDD stresses that point and builds on the strengths of TDD.
A single test can call multiple methods. Your tests should be isolated from other tests, not other code.
You want to be able to run tests quickly, otherwise you end up not running them at all. Code for tomorrow, design for today.
Work through this book, test it out for yourself.
Discuss test driven development online or with a coworker.
The more you share, the better you’ll understand it.