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.
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.