Common Myths and Misconceptions of Test Driven Development

Michael Larson on July 06, 2018

This is my first ever post on dev.to! I have been thinking about doing this for some time, I finally had a good enough idea to share with everyone ... [Read Full]
markdown guide

«Like most aspects of programming, testing requires thoughtfulness. TDD is a very useful, but certainly not sufficient, tool to help you get good tests.»

TDD stands for Test Driven DESIGN
you design your code with help of tests.

You dont write test for sake of tests. You dont blame TDD for not giving you good TESTS, because its not supposed to )


The acronym TDD is used for either meaning, and a quick google suggests that the ‘development’ version is more commonplace than the ‘design’ version. That doesn’t mean that the former is the only/right version, but it does contradict the idea that the latter version is necessarily the only/right version.


This is the first time I have heard someone use Test Driven Design! Thanks for sharing. Important point we can take away from this is that we need to give the same love and attention we give production code to our test code. The refactor phase is not just for our production code. If we don't we will end up with a tangled mess. Before I really understood and used TDD I thought that test code did't need to live up to the same standards as production code.


Yas as someone pointed out I drifted away with my thoughts on TDD to reinvent it as a TDDesign
however, I was trying to say what I said - for me TDD is there to guide you through development with better design, because it makes bad descisions stand out early )


I am a guy who really struggles to program TDD style because I lack self-discipline and have been not using tests at all for years. I am forcing myself to get into it, because I get increasingly frustrated with cases where a simple test would save me from a huge headache later on. Also, despite what people may think, it is faster to program with than without TDD, mainly because you immediately know if you broke something and it needs fixing, without you having to manually go through who knows how many use cases of you code. Without writing the tests from the start it is a real struggle to go back and write them.


Sounds similar to my experience. When I first started out I wrote no tests and tried testing everything manually myself. So hang in there! It will get better with pratice.

The time savings in my experience come from three areas. We spend less time in the debugger, we avoid logical errors and bugs that can suck large amounts of time, and we only write the bare minimum amount of code needed to get the tests passing.

One extra time saving I almost forgot about, if we really spend the time refactoring it can help us make our code easier to understand, which helps others save time.

Code of Conduct Report abuse