My Experiences of Test Driven Development (TDD)!

Introduction:

Test Driven Development (TDD) is a ‘buzz-term’ used all around Software Engineering.

Some people use it.

Some don’t.

Find out my experiences of it in this post.

What do I like about it?

What don’t I like about it?

As always, before we get into this week’s blog post, make sure to applaud, comment and share with your friends.

Happy Reading!

How I Got Into TDD:

Like I’ve said, first off it was just a fancy term that I’d heard around (online, at work …).

Then someone at work actually did a presentation on it.

Then I began seeing more online content about it.

Then a lot of time passed.

Eventually, a company in my local area started putting on “Coding Dojo” events (1 per month) where the whole idea was to solve a Leetcode-style problem with the intention of following the principles of TDD.

Thoughts on TDD:

TDD is great but I feel as though I would only really use it in these problem-solving styled scenarios as opposed to on actual projects.

Of course it adds an extra layer of clarity and allows us to improve the understanding of our code base. If there are unit tests for various cases then it makes it easier to interpret how different functions will work.

In my opinion, there needs to be a lot of familiarity/planning with the project. Expected/non expected behaviours must all be mapped out first otherwise there’s nothing to write tests for.

How faesible actually is it in the real world? To me it sounds good in theory rather than in reality.

Conclusion:

Overall I think that TDD has its place for particularly projects. With that being said, I don’t think it’s for me personally. I would never rule out using it. Testing is definitely important (something I’m trying to do more of within my own projects) and this

Final Things:

As always, thank you for taking the time to read this article!

All my links are here!