This is an installment in the What Biz People Need to Know About Tech series. It’s aim is to help non-technical business people to communicate better with engineers, and provide better feedback about the value they want them to deliver.
What is it?
Test driven development (commonly called “TDD”) is a technique that software developers use to get their work done. If you’ll allow me to make a music analogy, it’s like a guitar player using a pick to play a certain part as opposed to playing it fingerstyle.
If you’re a golfer, it’s like using a 65° wedge instead of a regular pitching wedge to sink a chip shot.
If you’re a rutabaga farmer, it’s like using nutrition blend 75 and double pruning instead of using the Barry Garbo method.
Okay… That rutabaga farming one isn’t real. I have no idea how to grow a rutabaga… but you get the idea.
What kind of technique?
Writing code can be tricky because we often need to satisfy a bunch of different behaviors with the same code. For example, let’s imagine that we are writing some code that calculates the total amount a customer owes at checkout time.
If you just dive in and start writing that code, it will probably go something like this
- I’ll make it sum up the price of all the items in the cart
- Next I’ll call the 3rd party service to calculate the tax.
- Then, I’ll make it so any account credit they have is deducted.
- Next, I’ll make it deduct the value of a coupon if the user has one.
- Oh wait, do they need to pay tax on the value before or after I apply the coupon?
It can be kind of like a cartoon character trying to plug leaks in a boat. Do you remember this? (I can’t find it on YouTube). A leak springs up and the character puts their finger in it to plug it. Then another pops up on the other side of the boat and they have to stretch to use their other hand to fix that one. Then they have to use their toe for the third, and so on.
Sometimes you get yourself in a situation where every time you make Thing A work, you break Thing B.
In our example above that would be like breaking the account credit calculation every time you make the coupon work, and then breaking the coupon when you go back and fix the account credit.
TDD lets the coder specify all of the things that the code needs to do before she writes the code itself. Those specifications exists forever and can be re-checked every time the code is changed.
Also, in 6 months when the developer has long forgotten if the coupon value is supposed to be taken out before or after the tax is calculated, the tests are still there to make sure everything still works correctly.
This effects the end product
A developer has to do things a little differently to do test driven development. It’s possible to write code that is hard or impossible to test. When a programmer is using TDD it causes the code to be designed in a different way.
The ways that the design is effected by TDD are almost always positive. I’m sure there’s some obscure situation where an un-testable design would be considered better, but I can’t recall ever encountering that situation in real life.
In practice, TDD improves code design.
What’s the value to the business?
The value to the business comes in two flavors:
- Less errors and bugs in production
- Faster development time
Long Term vs Short Term
Notice above that I said TDD makes development faster. Some people will say it a bit differently. They’ll say that TDD costs more time in the short term and saves time in the long term.
That’s technically true, but in my experience the balance point comes so soon that it’s more accurate to say that it’s just always faster. If the code I’m working on is going to be worked on for more than one day, I do TDD.
Test First vs Test After
Above I said that you write the specifications for the code before you write the code itself. That’s not the only way to do it, you can also write the tests afterwards and alter the code if what you started with doesn’t turn out to be easy to test.
Most developers do a mix of test-first and test-after development. I’m still okay with calling that TDD, although some people will say it’s only TDD if you write the tests first.
Do you have to do it to write good code?
Nope. Tons of companies get by without this particular technique in their tool belt. However, it’s becoming a pretty bad sign to not have tests as a part of you code base.
For the most part, once a developer learns to do test driven development well, they never go back to any other method.
There can be some… dogma
Developers can get “passionate” about this stuff….
I’m not sure that’s a good thing. TDD is a tool and tools are meant to help a person achieve a goal. TDD is not a goal in itself. Personally, I’m most impressed with a developer when they have laser sharp TDD skills, but understand that it’s just a way to build great stuff.
Developers who never learned to do it
It takes a long time to get good at test driven development. For an experienced developer who has years of experience writing code in a different way, it can feel like trying to throw a baseball with your wrong hand.
Because of this, you’ll run into people who have some pretty incorrect ideas about it. It can be good to ask someone how much TDD they have done before asking them what they think about it.
As I said above, it’s very rare that someone gets the hang of it and then decides they don’t want to do it anymore.
Summary
These days, you pretty much always want your developers to be writing tests. The tooling and learning materials have advanced to the point that it’s typically very easy to setup a test friendly development system.
It helps the business by making the development team able to move faster (over the long term) and by reducing errors.
It can be tricky to talk about this stuff with developers for a few reasons. They can be way too enthusiastic about it and forget that it’s just a tool. They can be defensive about it if they’ve never learned to do it. Generally, you want someone who can talk about the benefits of TDD, but doesn’t give off the vibe that it’s more important to them than the product itself.
I hope this was helpful to you. I hope you come back to read the next installment of What Biz People Need to Know About Tech.
Top comments (0)