Why You Should Consider Test Driven Development

Introduction

So I first would like to caveat this. I am making a case for TDD which if you are unfamiliar is Test Driven Development. However I'm keen to get others thoughts on this topic as well because it can cause division within the software development community and it's good to get different perspectives and thoughts on issues even if I/you don't agree.

TLDR

Test Driven Development allows the developer to hit these 4 markers:

• Well tested code.
• Alternate perspective.
• Bitesize functions.
• Catch bugs sooner.

What is TDD/Test Driven Development

This is a methodology for developing code. The process is as follows.

1. You are given a feature
2. You write test cases for the feature and the parts that make up that feature. These tests fail initially becuase the feature code isn't in place.
3. And you then write the code to get the tests to pass.

So just in case this isn't clear.

I want an adder function so I first write the test for that(I will write this in pseudo code).

void test_basic_adder_functionality(void)
{
    //! Given we have 2 numbers
    uint8_t a = 5;
    uint8_t b = 6;

    //! When we add these numbers together
    uint8_t actual_result = adder(a, b);

    //! Then we should get the added result correctly
    assert(11, actual_result);
}

We don't have adder defined yet so this test will fail. This is expected. No problem.

Now the next step is to create the function to do what we expect it to.

uint8_t adder(uint8_t a, uint8_t b)
{
    return a + b;
}

Now with the function implemented we can run the test and expect it to pass. Obviously there would be more tests to test edge cases but this hopefully gives you an idea of what exactly the mothodology is about.

Now you have a better understanding of TDD (that's if you didn't already) I can now outline key considerations on why TDD is a constructive method for developing software.

Your Code Will Be Tested

Pretty obvious this is. But the point is still valid. You can't follow the TDD method without writing tests. I've been guilty of this and still am at times. When not following the TDD format, especially in personal projects, open source projects and obviously work projects. The tests are like documentation, the boring part which gets pushed to the end or dare I say forgotten about completely!

The feature and implementation is the cool part of the job/hobby that we all get into software for. Not to test. Unless you work in a verification role and you like breaking software 😅

Alternate Perspective

So when writing code from a test perspective it allows you to think of things which you didn't think about. This is helpful as well if you implement test code coverage. But that's outside the scope of this post.

Writing tests first forces you to think about the outcome of the function you are aiming to test. This can help you visualise and break down the functionality you wish to test. Which leads me to my next point.

Bitesize Functions

It is very difficult to test large functions effectively. This is really clear when you try to add tests to an existing code base which can contain large functions.

When approaching a problem from a TDD perspective you start to write tests in a clear way and concise manner. Or at least I do and this is how I see it being useful. This then forces you to only write the functionality you need in the function to get the test to pass.

Catching Bugs

This is a big one and probably the biggest sell for test driven development. It allows developers to catch bugs before deployment. It's not a silver bullet to have 0 bugs. But minimising the number of bigs which occur is great. I don't enjoy debugging and I don't know many who do.

Even having basic tests catch silly code mistakes which could be avoided. Edge case tests avoid the more pernicious bugs that cause debugging headaches. I think this is something every developer strives for, perfect code with 0 bugs and in my experience TDD gets me close to that goal.

Bonus... Sort of: Dopamine Hit

Okay this isn't backed by any research, this is purely from a personal stand point. I love seeing all the tests I've written, pass. It gives me an ego boost too when the tests I've written pass and result in some green ticks on the CI/CD pipelines too. Again, I appreciate this won't vibe with everyone but if it vibes with 1 other person then I think it's worth sharing.

Conclusion

So I've explained TDD, given an example of how to go about using it and a few points which I feel are important to the TDD case. Do you agree? Do you disagree? Please give me some feedback. I'd love to hear the different perspectives on this.

And as always thank you for taking the time to read!