The clients don't pay for writing tests, the pay for code that works. That established, how much (percentage-wise) are you planning to spend on writing tests?
Brenan Keller @brenankeller wrote: "A QA engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.
First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone." (and that's my personal experience, writing gazillion tests and still failing at runtime)
TDDS are just as important as making small git commits or saving your work every 2 minutes; They are sort of insurance that you're not messing up, yet the unexpected will always surprise you.
Yes, TDD is great, but only when it makes sense (i.e. don't make it into religion);
Software developer trying to bring order into his craft. I write about my journey, thoughts, and practices. Currently focused on web frontend with React.
People certainly can take it too far and make it into a religion. Like it is some silver bullet that will solve all development problems when it won't. It's a technique that has its advantages and limitations, although I'd say it is one of the more useful ones I've come across. But I'm probably totally biased.
About point 2, I think it covers one of the limitations of TDD. TDD can never find an unexpected new bug in a system for a simple reason. We are the ones writing the tests, and that means that they are limited by our imagination. And, speaking for myself, we aren't very good at imagining all the ways our programs can break. We could try to stretch our imagination and write tons of tests, but then we end up with a codebase that's much harder to maintain than it needed to be. The way I found to deal with this issue is just to write enough tests to force me to implement a feature, and after the feature is "done" use exploratory testing to find bugs I didn't imagine could exist. And then write regression tests for those new-found bugs. It's been working great so far :)
I think item 1 does not consider the time spent on executing tests. When we work with software that keeps evolving during the time, writing tests makes you spend less time with tests then executing them manually every 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.
Yes, TDD is great, but only when it makes sense (i.e. don't make it into religion);
People certainly can take it too far and make it into a religion. Like it is some silver bullet that will solve all development problems when it won't. It's a technique that has its advantages and limitations, although I'd say it is one of the more useful ones I've come across. But I'm probably totally biased.
About point 2, I think it covers one of the limitations of TDD. TDD can never find an unexpected new bug in a system for a simple reason. We are the ones writing the tests, and that means that they are limited by our imagination. And, speaking for myself, we aren't very good at imagining all the ways our programs can break. We could try to stretch our imagination and write tons of tests, but then we end up with a codebase that's much harder to maintain than it needed to be. The way I found to deal with this issue is just to write enough tests to force me to implement a feature, and after the feature is "done" use exploratory testing to find bugs I didn't imagine could exist. And then write regression tests for those new-found bugs. It's been working great so far :)
I think item 1 does not consider the time spent on executing tests. When we work with software that keeps evolving during the time, writing tests makes you spend less time with tests then executing them manually every time.