While I concur with most of what you've shared, and am an advocate of TDD myself, I am also aware of and I suspect you could have discussed a little, some of the reasons it's not used as often as it could be.
The biggest of them is TTM (if we're going to indulge in TLA's let's indulge - in this case Time To Market). There's an old adage that comes in many paraphrased forms, so I'll offer you mine off-the-cuff: If you go to market when you're ready, you're going to market far too late, though there are more famous versions.
Couple a desire/need/push to reach market ASAP there are pressures to streamline everything of course, and TDD is most definitely on that radar as are many other niceties.
That said, the emergence of better and better test frameworks is making it easier and easier to start with test designs to code towards.
A second impediment, that relates to the first, but touches on a competing fashion is the desire for rapid prototyping or agile methodologies if you prefer (for which no funky TLA leaps out at us). Where the goal is to drive towards an MVP (yay, we did squeeze one in - Minimal Viable Product) prioritising the UI and UX (2LAs of course can masquerade as TLAs give Two and Three boths start with T, and I hope these two are basic vocab, but in case not, User Interface and User Experience) deliveries to get rapid client or end user feedback on the directions of the UX. To wit we could argue UX design and agile methodologies compete for team attention with TDD.
None of which means you can't have TDD, as I said, I'm an advocate, and it certainly starts with having key advocates among the stakeholders who prioritise investments (as what a team does is an investment), and if the budgets are generous enough there is room for UX design and TDD, and agile and a focus on TTM ...
The benefits of TDD of course are clear and that you touch on. Reducing the cost of bugs (finding, fixing and to reputation and goodwill if they reach market) producing a net saving ...
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.
I totally agree with this, I've experienced both sides. Having complete freedom and time, so of cource TDD is used. I also had and have many projects where the main priority is working fast, and tests are left aside.
Though in real production products, it's a freaking life saver to have tests
I'm personally much faster writing code with tests, and that's why I always do it. You have to test (right?) so how do you do it? Manually? and manual QA? That sounds like a way to not go fast. And unless your system is trivial, over time you will be introducing defects, you can't refactor/rewrite safely without introducing more defects, and a 'big ball of mud' ensues.
I worked for a startup which did TDD right from the start. We launched on time, and has one (yes one) defect on launch day. It's always faster to get to market with tidy code which can be refactored, bug fixed etc with confidence - no one wants to get to market first with a product that doesn't work (that's a good way to kill a startup) unless of course you're in that weird world (hello social media) where your users don't care if the software doesn't work very well or fails occasionally. I've yet to work in that space after 30 years.
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.
While I concur with most of what you've shared, and am an advocate of TDD myself, I am also aware of and I suspect you could have discussed a little, some of the reasons it's not used as often as it could be.
The biggest of them is TTM (if we're going to indulge in TLA's let's indulge - in this case Time To Market). There's an old adage that comes in many paraphrased forms, so I'll offer you mine off-the-cuff: If you go to market when you're ready, you're going to market far too late, though there are more famous versions.
Couple a desire/need/push to reach market ASAP there are pressures to streamline everything of course, and TDD is most definitely on that radar as are many other niceties.
That said, the emergence of better and better test frameworks is making it easier and easier to start with test designs to code towards.
A second impediment, that relates to the first, but touches on a competing fashion is the desire for rapid prototyping or agile methodologies if you prefer (for which no funky TLA leaps out at us). Where the goal is to drive towards an MVP (yay, we did squeeze one in - Minimal Viable Product) prioritising the UI and UX (2LAs of course can masquerade as TLAs give Two and Three boths start with T, and I hope these two are basic vocab, but in case not, User Interface and User Experience) deliveries to get rapid client or end user feedback on the directions of the UX. To wit we could argue UX design and agile methodologies compete for team attention with TDD.
None of which means you can't have TDD, as I said, I'm an advocate, and it certainly starts with having key advocates among the stakeholders who prioritise investments (as what a team does is an investment), and if the budgets are generous enough there is room for UX design and TDD, and agile and a focus on TTM ...
The benefits of TDD of course are clear and that you touch on. Reducing the cost of bugs (finding, fixing and to reputation and goodwill if they reach market) producing a net saving ...
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.
I totally agree with this, I've experienced both sides. Having complete freedom and time, so of cource TDD is used. I also had and have many projects where the main priority is working fast, and tests are left aside.
Though in real production products, it's a freaking life saver to have tests
I'm personally much faster writing code with tests, and that's why I always do it. You have to test (right?) so how do you do it? Manually? and manual QA? That sounds like a way to not go fast. And unless your system is trivial, over time you will be introducing defects, you can't refactor/rewrite safely without introducing more defects, and a 'big ball of mud' ensues.
I worked for a startup which did TDD right from the start. We launched on time, and has one (yes one) defect on launch day. It's always faster to get to market with tidy code which can be refactored, bug fixed etc with confidence - no one wants to get to market first with a product that doesn't work (that's a good way to kill a startup) unless of course you're in that weird world (hello social media) where your users don't care if the software doesn't work very well or fails occasionally. I've yet to work in that space after 30 years.