The sooner you start, the more bugs will be caught and the less work you'll need to do fixing them later on.
Coding is not about piling bugs, and TDD is not about fixing bugs that are not coded yet either. TDD is about defining requirements before implementing them.
In many cases, requirements are blurry, and in such situation TDD is a complete waste of time. Tests are also a way to ensure something that already works will continue to work the way it should. It's way faster to make a test from existing code and behavior to lock it as a requirement, rather than imagining and locking requirements for something that yourself are unsure on what behavior should be expected.
TDD is a tool and like any tools, it should be used when needed. Using it like an ideology might cost a lot in time and efforts when it's counter-productive.
So how can we identify when its counter-productive? What I mostly encounter is 'a mess with no tests' or 'a mess with tests' neither of which emerge from TDD. Mostly I see people not using it out of (I assume) ignorance. or reading comments like this.
What you are describing above is almost a straight quote from Michael Feathers' 'Working with Legacy Code' where you take a piece of code with uncertain behaviors, and write tests for it to capture those behaviors before you start modifying it. That's a bit like we used to be in (bad) waterfall days - write code, throw it over fence to QA, get them to test it, find defects, report back - a complete waste of eveyones time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Coding is not about piling bugs, and TDD is not about fixing bugs that are not coded yet either. TDD is about defining requirements before implementing them.
In many cases, requirements are blurry, and in such situation TDD is a complete waste of time. Tests are also a way to ensure something that already works will continue to work the way it should. It's way faster to make a test from existing code and behavior to lock it as a requirement, rather than imagining and locking requirements for something that yourself are unsure on what behavior should be expected.
TDD is a tool and like any tools, it should be used when needed. Using it like an ideology might cost a lot in time and efforts when it's counter-productive.
So how can we identify when its counter-productive? What I mostly encounter is 'a mess with no tests' or 'a mess with tests' neither of which emerge from TDD. Mostly I see people not using it out of (I assume) ignorance. or reading comments like this.
What you are describing above is almost a straight quote from Michael Feathers' 'Working with Legacy Code' where you take a piece of code with uncertain behaviors, and write tests for it to capture those behaviors before you start modifying it. That's a bit like we used to be in (bad) waterfall days - write code, throw it over fence to QA, get them to test it, find defects, report back - a complete waste of eveyones time.