Why Test-Driven Development

Test Driven Development (TDD) is a technique used by experienced software engineers to ensure the state of an application is as intended. In more traditional applications and within the journey of software engineering altogether, testing has been acknowledged and manifested to be part of every successful and professionally crafted software system. Nowadays, there are still tons of companies out there that have the impression that writing tests slows down development, increases costs, and in general is a waste of time. May this article shine a light on why this particular statement cannot be more wrong.

What Stops Software From Working?

There is no such thing as perfectly written software. (Probably) never will be. The term bug was first phrased at Harvard in 1946. At that time, Grace Hopper had popularised a story about a moth that caused problems in an early electromechanical computer. Hopper was working on the Mark II/III computer systems at Harvard where he identified that a moth was trapped in a relay causing problems.

Once the moth was removed Hopper phrased the statement within his notes: „First actual case of bug being found“. The term „bug“ was created and used ever since to indicate unexpected behavior in a computer system. What's the likelihood of a certain system having bugs? 100 out of 100 projects. What's the likelihood of having bugs within a certain system, if I hire the best engineers on this planet? 100 out of 100 projects. Hence, hiring better engineers does not solve the problem. It definitely will decrease the amount of bugs, but not their overall presence. That is why tests are written, as there is no error-free software.

Grace Hopper's bug (1946)

TDD: Cutting Costs, Enhancing Quality

In Test-Driven Development (TDD), engineers write tests before implementing the logic. Without going into technical details, this leads to the following: It ensures, if done properly, that no untested code is pushed to the repository as you have written a dedicated test upfront. Does this solve the bug problem we have discussed above? Unfortunately, no it does not. But it's one of the best techniques we have to ensure the creation of battle-tested and resilient software.

"Validate assumptions early to minimize costly mistakes later"

What's the difference with web3 now? Security is a top priority in Web3 development. Smart contracts often manage significant amounts of cryptocurrency and other valuable digital assets. Any vulnerability in these contracts can lead to substantial financial losses. TDD plays a crucial role in enhancing security by promoting continuous testing and early identification of potential issues.

By catching security flaws early in the development cycle, TDD helps protect against exploits and attacks that could compromise the integrity of a decentralized application. Testing enables engineers to adjust the code base and receive immediate feedback. If tests are written properly, any change to the code base that might lead to a bug will be caught by a test and reported.

Importantly, everything mentioned above can be done with simple testing too. Simple testing in the sense of writing a test whenever we think "now" is a good time. Many engineers follow the path: "I write the code now and once I have time, I'll write the test". Which is, to some degree, OK. Better than writing no tests at all! Yet it will never get the resilience levels of TDD, because it entirely misses the point. I happily repeat myself here: "No untested code will reach production". This is what pure TDD ensures.

Having no tests at all will eventually backfire

The Silent Killer: Technical Debt

Now I still owe you an explanation as to why omitting to write tests will skyrocket engineering and maintenance costs. The key word is technical debt. Software will always contain bugs. The longer it exists and the bigger it becomes, the more bugs it will produce. This is not something I came up with to underline this section, it is a well-known fact. Consequently, If there is no countermeasure to find and eliminate these bugs, they will live on and influence code that is added to the code base. Regularly. The more features we add to that software, the bigger the problem gets. And then one day, the tower collapses and you are standing in front of a no longer controllable code basis.

Leading to a total or partial rebuild of your project.

Picture a small town that decides to build a bridge quickly to connect two sides of a river. The engineers, in their rush, skip some safety checks and use lower-quality materials. Initially, the bridge works fine, and everyone is happy with the swift completion. As time goes on, more and more cars start using the bridge. Small cracks appear, but they are ignored because the bridge is still standing. Every new vehicle adds stress, making those cracks larger. One day, a heavily loaded truck drives over the bridge, and it collapses, causing a massive disruption.

This is what happens with technical debt in software. Early shortcuts and untested code create hidden problems. As new features are added, these problems grow until the system becomes fragile. Eventually, a seemingly minor change can cause a catastrophic failure, just like the overloaded truck did to the bridge. Without tests to catch and fix issues early, the software becomes unsustainable, leading to skyrocketing costs and, ultimately, collapse.

Advice #1: Whenever you hire developers, test their proficiency in testing by asking simple questions:

→ What is your experience with writing tests?
→ Which kind of tests do you prefer for this project, and why?
→ Do we really need to write tests?

Advice #2: If they give a S* about testing, they give a S* about your product.

Sounds harsh, but is the truth.

Your project will eventually die without testing, that is for sure.