TDD: Show Me The Code
Enough Theory. A series of posts showing what TDD looks like in practice.
As a Github Open Source contributor, I always found it hard to share content that could explain certain concepts and fundamentals clearly. I always found myself repeating the same thing over and over again in Github comments and the workplace.
This is one of the reasons I’ve started writing: to create open content that I can use to share and spread knowledge. To have something I can use to point someone in the right direction.
Test-Driven Development is one of those fundamentals highly misunderstood by developers. The majority of the posts out there only talk about it on the surface. There’s rarely something that goes deep into the subject.
I want to change that.
In the past few weeks, I’ve written a series of posts to show the First Principles of TDD using JavaScript.
Here’s a summary of them (click on the title for the details):
The Missing Practical Step-By-Step TDD
This post kicks off with the story of Jack, The Moneylender. Jack hires a developer and puts a deadline for the work to finish. However, because of TDD, the developer manages to have working software in a fraction of the time it would take to develop the whole specification.
This post also shows why you need small tests instead of one test that drives you to implement the whole thing.
Create one test and write the most straightforward code to make it pass. Don’t create one test and then write the whole thing.
How To Build A Money Data Type In JavaScript
This post solves the problem of using the JavaScript Number type to represent dollars and cents. If you’re not aware of floating point arithmetic issues, you only discover the problem of using the JavaScript Number type to represent money when it fails in production.
Test what you know. You can’t test what you don’t know.
The Code You Write Should Only Suck Less Than The One Before
This post describes the lessons I learned while developing this TDD series. It also shows that you shouldn’t expect to get a good code during the first attempt at solving a problem. TDD facilitates Continuous Improvement; the code only gets better with practice.
There’s no silver bullet, the code you write only gets better with practice.
This Is The One Thing Nobody Told You About TDD
This post shows how TDD is not about tests; it’s about driving. You write one small test after the other, each test drives you to make the code more generic.
Besides, if you follow the fundamentals of TDD, you don’t need to associate a failing test from a test framework with the “red phase” or a successful test with the “green phase.” You can practice TDD on a different level, where the message from a syntax error represents the “red phase” and a fix represents the “green phase.” As long as both the first and second messages are predictable, it doesn’t matter which tool you use to see them.
The important thing here is that you only change the code after you get a Negative Feedback from running it, regardless of the tool you use.
You can only change the code you can run.
How TDD Can Prevent Over-Engineering
This post shows how TDD can allow you to refactor the code without the risk of breaking it. It’s a discipline that forces you only to write the code you need, as long as you already have the skills to go in the right direction.
If you always create a test to justify the code you write, then you never have to worry about writing the code you don’t need.
What drove me to write this series is the general misunderstanding of the value of Test-Driven Development in the programming workflow.
If you’re reading this and believe it’s not worth bothering to look at the posts because you already know TDD, I still recommend taking a look and give me some feedback of what you think.
One of us might learn something.
TDD allows you to understand the problem and build a good product for humans, not to write code so that the tests pass.
Why the moneylender? Why not using something else as an example?
Coding the calculation of interest rates for Jack seems like you’re helping a loan shark, which is a very unethical job. After all, you’re helping to take money out of people in a vulnerable position. Unfortunately, the reality is most people don’t care.
In programming, some people start their career working in borderline unethical projects to get more experience because that’s the only job they can get. After they get more experience, they move to other projects that are less unethical while the old company replaces their roles.
I wrote about a moneylender so that you can read this post and pretend to work in an unethical environment. This way, you don’t need to work for one in real life and still get the experience.
Pretend to work in unethical projects so that you don’t need to work with one where you can cause real harm
The programming problem for “Jack, The Moneylender” was inspired in an interview exercise I did for a company. In that case, when I walked through the door, I didn’t know the details of the problem or the solution. Instead of a take-home exercise, they gave the opportunity to do Pair Programming with me acting as the navigator. That opportunity allowed me to show the value of TDD and ask the right questions and solve the problem quickly.
After the interview, they understood more than what they previously knew about what was possible with TDD.
You can discover a solution. You don't need to know it upfront.
I wrote this series because the internet has lost the fundamentals of TDD. The internet is full of articles about TDD; only those articles don’t explain the First Principles.
When somebody asks me, I find it very hard to provide a good source that explains TDD to the barebones. Most of the content is hidden inside books, which are no different than a website with a paywall.
The internet is open and free, but it also forgets.
I hope you don’t forget this one.
