When TDD impact business timelines, it most definitely should not be done.
Some say that TDD is no slower because of the safety net it provides, and you don't have to fix bugs later.
To that, I always ask "how does TDD save me from bad requirements?"
I would also add, regardless of language, senior developers are usually writing testable code by default - otherwise they're probably not all that senior. So in their case, writing tests after the fact doesn't tend to suffer from the refactoring cycle.
Writing a test first converts the requirements into concrete language. If you can't write the test, it shows that you need to go back to your Product Owner and get clarification - it's actually superb at saving you from bad requirements. Otherwise how do you write the code? Waiting until QA (or even later) to find a requirements defect always costs more (its called the hockey-stock cost-to-change curve) deepsource.io/blog/exponential-cos...
My problem here, is that you're talking in absolutes.
"If you can't write the test, it shows that you need to go back to your Product Owner..."
Does it though? Maybe you're just a junior and need guidance from others on the team? There's a myriad of other reasons I can think of that tests might not be possible/easy/time efficient (esp. when writing a POC, for that last one).
"...it's actually superb at saving you from bad requirements."
Superb? Perhaps. But will TDD always catch a bad/incomplete requirement? No. You could always be following TDD and SRP religiously, write a perfectly valid test, but break some other area of the system (and if that other area isn't covered by tests, regardless of when the tests were written, we have regression...).
Do you think you, or someone else at your work has a complete and true, and always up to date picture in their head about how the system functions, and how users interact with it? At least the talk I saw from Dave Hahn was very clear to point out that NO-ONE at Netflix holds the full system in their head.
I don't think I ever argued for "QA (or even later) to find a requirements defect..." Did I?
'writing tests after the fact' is not TDD. I've just come from a project with 97% test coverage mostly written after the fact. They were nearly all full-stack tests (using a browser and Selenium) and the code underneath was a pile of garbage with many defects. It took the team 2 years to wrangle the (pretty small) code-base to a point of sanity - there was massive copy-paste, violation of 3NF in the database schema, hard-rolled forms not using the platform libraries, no database foreign keys. TDD is a design technique infoq.com/articles/test-driven-des... so writing tests second is something else entirely, with output that looks superficially similar.
Re your project with 97% test coverage, that sounds like a legacy project, with all the trappings that come with legacy projects, and someone that devised a test strategy that wasn't effective (we can get into the debate of "how to effectively measure test coverage" debate if you really like...).
Also, thanks for the links, but I don't need an education in what the concepts are... my comments are more aimed at figuring out when and why people use different strategies, so that I might be able to tweak our approach to solving problems (be those in the code, or in the rest of the business). I manage a team of developers, working on in excess of 50 software projects spread across 5 different geographical locales.
TDD, BDD, Scrum, Agile, SRP, 3NF etc etc, are all perfectly valid principles & ideas. The key, is in knowing when to use each, and why, and when to avoid (or modify) other people's ideas.
So when you don't use each of these things, what do you do instead? I see lots of detractors for TDD (including 'TDD is only for juniors') without anyone suggesting an alternative strategy
Did I say "TDD is only for juniors" ? Nope... didn't think so.
It's a little difficult to state what techniques (plural) we use whenever TDD isn't appropriate, because the technique we use depends upon a lot of context. Sometimes, hell, even often TDD is appropriate, so we use that.
"Appropriate tool for the job" - isn't just limited to languages & frameworks, working methodologies too. Much the same as some of our projects are waterfall, some Scrum, some LEAN, etc etc.
If you're aware of TDD, and maybe even like it, chances are you're aware of the alternatives.
I'm actually a strong advocate for TCR, but I'm also a realist and accept that it isn't always applicable, and the "test" part of TCR doesn't have to be unit tests. Also, we use gitflow, so I don't care that every commit is tested, but every merge is - one way or another.
My big issue with talking in absolutes, is that none of this debate proves that any code written, by any method, is 100% bug free or is 100% what the end users wanted/needed. Of course, I also acknowledge that 100% perfection is a myth.
I guess, ultimately, we follow ADD more than anything else, but even then, we follow our version of it.
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.
When TDD impact business timelines, it most definitely should not be done.
Some say that TDD is no slower because of the safety net it provides, and you don't have to fix bugs later.
To that, I always ask "how does TDD save me from bad requirements?"
I would also add, regardless of language, senior developers are usually writing testable code by default - otherwise they're probably not all that senior. So in their case, writing tests after the fact doesn't tend to suffer from the refactoring cycle.
Writing a test first converts the requirements into concrete language. If you can't write the test, it shows that you need to go back to your Product Owner and get clarification - it's actually superb at saving you from bad requirements. Otherwise how do you write the code? Waiting until QA (or even later) to find a requirements defect always costs more (its called the hockey-stock cost-to-change curve) deepsource.io/blog/exponential-cos...
My problem here, is that you're talking in absolutes.
"If you can't write the test, it shows that you need to go back to your Product Owner..."
Does it though? Maybe you're just a junior and need guidance from others on the team? There's a myriad of other reasons I can think of that tests might not be possible/easy/time efficient (esp. when writing a POC, for that last one).
"...it's actually superb at saving you from bad requirements."
Superb? Perhaps. But will TDD always catch a bad/incomplete requirement? No. You could always be following TDD and SRP religiously, write a perfectly valid test, but break some other area of the system (and if that other area isn't covered by tests, regardless of when the tests were written, we have regression...).
Do you think you, or someone else at your work has a complete and true, and always up to date picture in their head about how the system functions, and how users interact with it? At least the talk I saw from Dave Hahn was very clear to point out that NO-ONE at Netflix holds the full system in their head.
I don't think I ever argued for "QA (or even later) to find a requirements defect..." Did I?
'writing tests after the fact' is not TDD. I've just come from a project with 97% test coverage mostly written after the fact. They were nearly all full-stack tests (using a browser and Selenium) and the code underneath was a pile of garbage with many defects. It took the team 2 years to wrangle the (pretty small) code-base to a point of sanity - there was massive copy-paste, violation of 3NF in the database schema, hard-rolled forms not using the platform libraries, no database foreign keys. TDD is a design technique infoq.com/articles/test-driven-des... so writing tests second is something else entirely, with output that looks superficially similar.
Strawman detected!
"'writing tests after the fact' is not TDD."
I never argued to the contrary.
Re your project with 97% test coverage, that sounds like a legacy project, with all the trappings that come with legacy projects, and someone that devised a test strategy that wasn't effective (we can get into the debate of "how to effectively measure test coverage" debate if you really like...).
Also, thanks for the links, but I don't need an education in what the concepts are... my comments are more aimed at figuring out when and why people use different strategies, so that I might be able to tweak our approach to solving problems (be those in the code, or in the rest of the business). I manage a team of developers, working on in excess of 50 software projects spread across 5 different geographical locales.
TDD, BDD, Scrum, Agile, SRP, 3NF etc etc, are all perfectly valid principles & ideas. The key, is in knowing when to use each, and why, and when to avoid (or modify) other people's ideas.
So when you don't use each of these things, what do you do instead? I see lots of detractors for TDD (including 'TDD is only for juniors') without anyone suggesting an alternative strategy
Did I say "TDD is only for juniors" ? Nope... didn't think so.
It's a little difficult to state what techniques (plural) we use whenever TDD isn't appropriate, because the technique we use depends upon a lot of context. Sometimes, hell, even often TDD is appropriate, so we use that.
"Appropriate tool for the job" - isn't just limited to languages & frameworks, working methodologies too. Much the same as some of our projects are waterfall, some Scrum, some LEAN, etc etc.
If you're aware of TDD, and maybe even like it, chances are you're aware of the alternatives.
I'm actually a strong advocate for TCR, but I'm also a realist and accept that it isn't always applicable, and the "test" part of TCR doesn't have to be unit tests. Also, we use gitflow, so I don't care that every commit is tested, but every merge is - one way or another.
My big issue with talking in absolutes, is that none of this debate proves that any code written, by any method, is 100% bug free or is 100% what the end users wanted/needed. Of course, I also acknowledge that 100% perfection is a myth.
I guess, ultimately, we follow ADD more than anything else, but even then, we follow our version of it.