DEV Community

loading...

Discussion on: TDD Practicality

Collapse
cariehl profile image
Cooper Riehl • Edited

Why is TDD always a good idea?

Only a Sith deals in absolutes...

I strongly believe in TDD as an effective way to design code that can be easily tested and verified. I think TDD is an important concept to keep in mind when starting a new project. Sadly, we can't apply TDD to every single project we work on, primarily due to time constraints.

Why might TDD ever be a bad idea?

The biggest "issue" with TDD is the additional overhead that gets added to the project as a result. It takes time to write and document tests up-front. It takes time to train our fellow developers on our tests, and the TDD process in general.

I will almost always argue that this overhead is worthwhile, and that the up-front complexity of TDD will pay itself off in spades when the project must be modified in the future. Unfortunately, there are real-world scenarios where we must meet a tight deadline, and we simply don't have time to follow all of the best practices.

Sometimes, we need to write a new component in the middle of several layers of existing services, none of which are being tested properly. In order to apply TDD here, we may need to write additional tests for components other than the one we are modifying, or we may need to create an excess of "fake" components in order to test our new one effectively.

Sometimes, we have to create a "proof-of-concept" project on a tight schedule. If we spend the time to focus on TDD, our product may not make it to market in time to beat the competition.

I believe it is most common for TDD to be ignored when the priorities of the project become "functionality > maintainability". Working on these projects sucks, because as developers, we know that we're just creating a mountain of technical debt that will have to be addressed later. However, sometimes we really do just have to "bite the bullet" and get something working, and pray that we have the time later to come back and improve it.

Collapse
stevekaufman profile image
Steven Kaufman Author

Sadly, we can't apply TDD to every single project we work on, primarily due to time constraints.

Is that so?

If we spend the time to focus on TDD, our product may not make it to market in time to beat the competition.

This is another subject Bob Martin touches on. The myth (according to Bob) that being 'first to market' is of the utmost importance. "Was Facebook first to market?" he asks. And, of course, neither was Google. But you don't see people walking around using 'Yahoo' as a synonym for internet search or even mentioning MySpace.

It's really a misunderstanding of the Lean startup philosophy, which says that startups should quickly produce a minimum viable product and rely heavily on consumer feedback so that they can quickly adapt. This ability to quickly adapt is key, and is actually enhanced by TDD.

The word viable is also important here. A minimum viable product (in software), I would argue is not a mess of code that barely works, but a well-done piece of software that is perhaps missing some of the features that would be necessary to call it 'done' or 'ready' from a business perspective.

The only way to go fast is to go well - Bob Martin

Collapse
cariehl profile image
Cooper Riehl • Edited

The myth (according to Bob) that being 'first to market' is of the utmost importance.

You have good insight. I agree with you, and Uncle Bob, that "first to market" should not be a company's primary motivation.

startups should quickly produce a minimum viable product and rely heavily on consumer feedback so that they can quickly adapt. This ability to quickly adapt is key, and is actually enhanced by TDD.

100% agree. If I ever create a new product, I plan to approach it with this in mind. Prototypes and minimum viable products have their benefits, but they should never be considered the "end goal". They should always be a single step on the journey towards a well-maintained, easily-extensible, clean and functional system. It sounds like you understand this very well.

I think your interpretation of TDD theory is spot on. I'll end with a single piece of advice, for you and anyone else reading.

As developers, we love to think about the "ideal scenario". Full test coverage, beautifully clean interfaces, proper documentation, etc. There's a reason we love these things - it's because they're proven to be effective, when they exist. Unfortunately, we rarely have time to implement all of our ideals.

When we're faced with deadlines (whether it's from management, another team, ourselves, or other circumstances) we have to pick and choose which best practices we want to follow, and we even have to limit how much time we spend researching all the options. In these scenarios, it's important to understand what each practice brings to the table, and which ones will be the most effective for our project.

And if we are forced to ignore best practices too often, it's important to remember that we can always find another job ;)

Collapse
theowlsden profile image
Shaquil Maria

Totally agree with this comment. Good explanation!👌🏾

Collapse
cariehl profile image
Cooper Riehl

Thank you, I appreciate it! 😊

Forem Open with the Forem app