All lovely sentiments. I wish I lived on the same planet.
Re the size of my pants - I refuse to release anything to QA without a minimum of 60% test coverage (I won't get into the intricate debate here of how to measure). Doesn't matter if I wrote it or someone else on my team wrote it - no minimum coverage, no release.
PMO often push for a full feature set, on the timeline they demand. Same in every company I've worked for. So I made a point of having the CI server enforce code coverage, so no-one can push an untested release.
Testing, or not testing, wasn't the debate (nor were the size of my pants).
The point, is that TDD requires perfect requirements (or a locked sprint) otherwise you'll be wasting time by writing tests at the start, because the requirements will change.
We have someone on my team who loves TDD, advocates for it at every step, and then takes 5 times as long as everyone else to actually deliver.
I'm not speaking from an untested world here. TDD has only two valid use cases; bug fixing and some dystopian perfect realm where requirements are written by a BA that understands the user base perfectly.
I am a self-taught developer from Argentina currently living in Spain. I am passionate about improving my technical skills and helping others do the same.
Hey Dave thank you for answering back, I am sorry if my answer seemed attacking to you in any sense 'cause that was not the idea at all. I wasn't talking about you specifically, me and a lot of developers I know sometimes we don't push stuff when it is our responsibility, we let other parts of the development team decide for us when building the product is done with our decisions.
I also worked in multiple companies were scenarios happen as the way you describe them, it's not until my last experience that I understood that we can all work together and improve that situation.
On the part of TDD I don't agree that you need perfect requirements, I work in an environment that requirements change all the time, and features never end up as they were originally planned, still I have not seen TDD come into trouble with this, in the long term we had produce much better code when having a testing suite written in a TDD manner ( due to having a high test coverage and covering very weird edge cases), it is also very easy to change requirements and refactor when you have this already implemented, changes are done with ease because you have a clear view if you broke previous features.
About the time it takes to develop, after the initial time, do you have any knowledge that the code the guys without TDD produced was much safer or even equally safer than the one produced with TDD?
I can only speak from my experience but when consciously using TDD in specific modules of our application the bugs that came from it drastically reduced due to the benefits I mentioned previously.
In my case I don't advocate that everyone should do TDD, I am just mentioning the reasons why I love TDD and why I do it. It happens that my team does TDD, but other teams in the company don't.
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.
All lovely sentiments. I wish I lived on the same planet.
Re the size of my pants - I refuse to release anything to QA without a minimum of 60% test coverage (I won't get into the intricate debate here of how to measure). Doesn't matter if I wrote it or someone else on my team wrote it - no minimum coverage, no release.
PMO often push for a full feature set, on the timeline they demand. Same in every company I've worked for. So I made a point of having the CI server enforce code coverage, so no-one can push an untested release.
Testing, or not testing, wasn't the debate (nor were the size of my pants).
The point, is that TDD requires perfect requirements (or a locked sprint) otherwise you'll be wasting time by writing tests at the start, because the requirements will change.
We have someone on my team who loves TDD, advocates for it at every step, and then takes 5 times as long as everyone else to actually deliver.
I'm not speaking from an untested world here. TDD has only two valid use cases; bug fixing and some dystopian perfect realm where requirements are written by a BA that understands the user base perfectly.
Hey Dave thank you for answering back, I am sorry if my answer seemed attacking to you in any sense 'cause that was not the idea at all. I wasn't talking about you specifically, me and a lot of developers I know sometimes we don't push stuff when it is our responsibility, we let other parts of the development team decide for us when building the product is done with our decisions.
I also worked in multiple companies were scenarios happen as the way you describe them, it's not until my last experience that I understood that we can all work together and improve that situation.
On the part of TDD I don't agree that you need perfect requirements, I work in an environment that requirements change all the time, and features never end up as they were originally planned, still I have not seen TDD come into trouble with this, in the long term we had produce much better code when having a testing suite written in a TDD manner ( due to having a high test coverage and covering very weird edge cases), it is also very easy to change requirements and refactor when you have this already implemented, changes are done with ease because you have a clear view if you broke previous features.
About the time it takes to develop, after the initial time, do you have any knowledge that the code the guys without TDD produced was much safer or even equally safer than the one produced with TDD?
I can only speak from my experience but when consciously using TDD in specific modules of our application the bugs that came from it drastically reduced due to the benefits I mentioned previously.
In my case I don't advocate that everyone should do TDD, I am just mentioning the reasons why I love TDD and why I do it. It happens that my team does TDD, but other teams in the company don't.
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.