Re the general productivity of the TDD advocate on my team - pretty much everything they touch is a bug riddled mess (functional issues). It's so bad that most of the PMO won't even give them work to do.
But, see my post on code reviews... same person, and I'm confident it says more about that individual than it does TDD.
Re code coverage, you're entirely right, if we release at 60%, 40% is not covered by tests. But that doesn't mean we haven't manually tested those areas, or that we haven't given the QA team a heads up on where we are weak with tests...
My 2 cents.
Although what Pat says, sounds more appropriate theoretically, but I have to side with Dave here, for he says the brutal truth.
TDD can be a great practice when you are, may be, building your own small-mini-side project at home.
But when you work for an enterprise, you cannot practically do 100% TDD for any real business deliverables.
You should write tests to test a piece of logic, both positive & negative, if it makes sense to your business purpose.
With so many frameworks around these days, there is so much boiler-plate code, that it does not make any sense to follow a true TDD approach.
Also, in enterprise level apps, more often than not, there is no need to test all 100% plausible and implausible scenarios. Mostly, you know there are N number of known scenarios you can write tests for those, both positive as well as well negative, and then encompass all of the rest inconsequential scenarios in 1 single bucket of failure or the bucket of "do not care".
With so much debate going on about true-blooded TDD and all, but what I feel is that it is more important to understand the business value of what we are doing, and use our practical experience to apply the correct logic in solving that problem.
There is no point in solving a non-problem which nobody cares & keep on writing innumerable test cases. I mean, practically speaking, u cant possibly think of ALL the different scenarios for a given situation. Even if someone does, I am sure someone else can come up with one more. So, let us not go down the rabbit hole.
Rather put our energy in identifying what matters to the business and solve that, then move on to the next problem.
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.
Re the general productivity of the TDD advocate on my team - pretty much everything they touch is a bug riddled mess (functional issues). It's so bad that most of the PMO won't even give them work to do.
But, see my post on code reviews... same person, and I'm confident it says more about that individual than it does TDD.
Re code coverage, you're entirely right, if we release at 60%, 40% is not covered by tests. But that doesn't mean we haven't manually tested those areas, or that we haven't given the QA team a heads up on where we are weak with tests...
My 2 cents.
Although what Pat says, sounds more appropriate theoretically, but I have to side with Dave here, for he says the brutal truth.
TDD can be a great practice when you are, may be, building your own small-mini-side project at home.
But when you work for an enterprise, you cannot practically do 100% TDD for any real business deliverables.
You should write tests to test a piece of logic, both positive & negative, if it makes sense to your business purpose.
With so many frameworks around these days, there is so much boiler-plate code, that it does not make any sense to follow a true TDD approach.
Also, in enterprise level apps, more often than not, there is no need to test all 100% plausible and implausible scenarios. Mostly, you know there are N number of known scenarios you can write tests for those, both positive as well as well negative, and then encompass all of the rest inconsequential scenarios in 1 single bucket of failure or the bucket of "do not care".
With so much debate going on about true-blooded TDD and all, but what I feel is that it is more important to understand the business value of what we are doing, and use our practical experience to apply the correct logic in solving that problem.
There is no point in solving a non-problem which nobody cares & keep on writing innumerable test cases. I mean, practically speaking, u cant possibly think of ALL the different scenarios for a given situation. Even if someone does, I am sure someone else can come up with one more. So, let us not go down the rabbit hole.
Rather put our energy in identifying what matters to the business and solve that, then move on to the next problem.