You Don’t Know TDD
Tags: javascript, softwaredevelopment, agile, programming
Published: 2023-05-13 05:43:25

---
title: You Don’t Know TDD
published: true
tags: javascript,softwaredevelopment,agile,programming
canonical_url: https://fagnerbrack.com/you-dont-know-tdd-691efe670094
---

#### Seriously

![](https://cdn-images-1.medium.com/max/1024/1*8-HqH4FZy1Hg-iisYLXZpA.jpeg)<figcaption>The cover image of this post shows a composite of 5 pictures. The first one, from left to right, shows a bald man with a short beard. He’s counting some money in a table and smiling. There’s a dark shadow surrounding him. The second picture shows a massive flame from a <a href="https://en.wikipedia.org/wiki/Fire_breathing">Fire Breathing</a> act. The third one shows the photo of a hotel’s bedroom. The fourth picture shows a blacksmith using a hammer to hit a piece of iron on top of an anvil. The last picture shows a bald man with a short beard. He’s using a computer on a table and smiling. It’s the same bald man from the first picture, only now there’s no dark shadow surrounding him.</figcaption>

As a [Github Open Source](https://hackernoon.com/lets-implement-the-open-source-model-but-which-open-source-a89c82d1b494) contributor, I always found hard to share content that could explain certain concepts and [fundamentals](https://hackernoon.com/the-doctor-and-the-scalpel-78656f508c9a) 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](https://hackernoon.com/the-doctor-and-the-scalpel-78656f508c9a) 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](https://en.wikipedia.org/wiki/First_principle) of TDD.

Here’s a summary of them:

#### [The Missing Practical Step-By-Step TDD](https://dev.to/fagnerbrack_2/the-missing-practical-step-by-step-tdd-ih9-temp-slug-5508164)

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](https://dev.to/fagnerbrack/how-to-build-a-money-data-type-in-javascript-4ko5-temp-slug-9291700)

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](https://dev.to/fagnerbrack_2/the-code-you-write-should-only-suck-less-than-the-one-before-4o9n-temp-slug-2035498)

This post describes my learnings while developing this TDD series. It also shows that you shouldn’t expect to get a good code in the first time you try to solve a problem. TDD facilitates [Continuous Improvement](https://hackernoon.com/how-to-understand-the-balance-between-learning-and-progress-6783e7f711ac); the code only gets better with practice.

> There’s no [silver bullet](https://fagnerbrack.com/how-to-reject-the-belief-on-the-silver-bullet-1d86b686acbb), the code you write only gets better with practice.

#### [This Is The One Thing Nobody Told You About TDD](https://dev.to/fagnerbrack/this-is-the-one-thing-nobody-told-you-about-tdd-102-temp-slug-1786179)

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 see the failing test from a test framework for the “red phase” or a successful test for 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](https://en.wikipedia.org/wiki/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](https://dev.to/fagnerbrack_2/how-tdd-can-prevent-over-engineering-52f1-temp-slug-5501597)

This post shows how TDD can allow you to refactor the code without the risk of breaking it. It’s a [discipline](https://hackernoon.com/how-to-fix-the-software-industry-c2b627ec3d9d) that forces you only to write the code you need, as long as you already have the skills to go in the [right direction](https://hackernoon.com/the-journey-for-the-right-question-c3f5b9e90035).

> 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](https://en.wikipedia.org/wiki/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](https://news.ycombinator.com/item?id=17692005).

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](https://fagnerbrack.com/pair-programming-8cfbf2dc4d00) 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](https://hackernoon.com/the-doctor-and-the-scalpel-78656f508c9a) of TDD. The internet is full of articles about it; only those articles don’t explain the [First Principles](https://en.wikipedia.org/wiki/First_principle).

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.

Thanks for reading. If you have some feedback, reach out to me on [Twitter](https://twitter.com/FagnerBrack), [Facebook](https://www.facebook.com/fagner.brack) or [Github](http://github.com/FagnerMartinsBrack).

Thanks to **Danil Suits, Jamie Isaacs** for his insightful inputs to this post.