At the moment I’m working on a project where I’m more of a YAML engineer than anything else. During this time, I kind of enjoy getting my hands on actual code again, but most of the time, writing code is a rarity for me. So, whenever I find a cool idea to work on, I usually start a new side project. Something I try to incorporate as soon as possible is Test Driven Development (TDD).

While I agree that initially TDD may not fit into the ideation phase of your project where you’re still trying to figure what you’re doing, but as soon as you’re evolving TDD really speeds up your development.

Let me show you how TDD can up your coding game ! 🚀

Refactoring Becomes Part of Your Workflow

While I was working on my side project, something I immediately noticed after applying TDD to it was that refactoring became a part of my development workflow. That’s a great thing, right? I mean, how many times have you looked at code thinking:

“Damn that thing should’ve been refactored a long time ago”.

With TDD, you’re refactoring your code more often, simply because you’re wiring it directly into your workflow. Every test you write forces you to think about the design of your code, and since writing tests has now become a first-class citizen in your code, you’re more likely to refactor your code so that it remains easy to test.

Shorter Feedback Cycles

By practicing TDD, you’re forcing yourself into a constant feedback loop, iterating on the implementation and the design of the code. By writing the test first, you’re already investing in the design because you have to think about what your function will return, whether it has a side effect you need to capture, and so on. This leaves you with code that is testable right from the start and easy to refactor later on, since you already have tests covering your existing functionality. As you’re in a constant cycle of writing a test, implementing the functionality, and refactoring your code, your feedback loop is way shorter than writing the implementation, starting up the application, and refactoring/fixing bugs afterward.

Less cognitive complexity

Test-driven development encourages you to think about one thing at a time, which really helps to reduce the cognitive complexity during the implementation and while reading the code. More often than not, we get assigned features that contain a lot of business rules, errors, and edge cases. Keeping track of all those things during development can be a real pain.

TDD can help you manage this complexity. If done properly, the acceptance criteria of your feature directly translate to the tests you write. So, in a test-driven fashion, you start writing a test for your first acceptance criterion, implement it, and move on to the next one. This way, you can focus on one part of your feature at a time, and you don’t have to worry about introducing yet another edge case, since your tests have your back right from the beginning. If you don’t use TDD, you might be inclined to implement all the acceptance criteria at once, thus putting a huge load on your brain.

Separating Business Logic from Side Effects

Another benefit of Test Driven Development that I absolutely love is that it forces you to keep your business logic pure and keeps the side effects on the edges of your application. Side-effectful code can really be a nightmare to test or debug, as it does things you might not expect it to do.

Since TDD enforces your code to be testable, naturally, you tend to push side-effectful code, such as network requests, to the edges of your application so that your business logic is deterministic.

TL;DR

Test-driven development is obviously not a silver bullet, and it has to fit your development workflow. In most cases, I think TDD brings a lot to the table and will generally produce better code.

In essence, I’d suggest you give it a try, since there is much to gain and not much to lose anyway. Take a kata and check it out!