Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
I'm sorry to tell you that they're right.
That is how software quality can be guaranteed.
And this fact is priceless, since in IT there is almost no chance for a guarantee.
On the other hand it is important that 100% code coverage was reached by using real unit-tests where non of this tests has a fixed dependency on another unit/class!
@TylerDDevRant , don't be sorry. You are certainly entitled to your opinion just as they are. I just happen to disagree with you completely. Test coverage in no way equates with or guarantees quality. I can write crappy code and meaningless tests and end up with something that doesn't work and nobody wants. Tests are smoke alarms. They tell you if something that you don't want to change has changed. That's all ( not to diminish the importance of knowing that for important things). We have unit tests that count the number of system colors in Windows. We have integration tests that fail sporadically because they try to measure performance against arbitrary constants but run in and uncontrolled environment. Tests are only of value if they test something of value and they never guarantee a level of quality in what is being tested.
I agree with you.
Unit-testing without using TDD is only half the share.
This constellation leads to the overkill you described.
But any developer with experience - and by experience I mean the number of "Boss: What have you fucked up. Nothing works anymore. Dev: Sorry. I have no idea. I will spend a bunch of hours/your money to find the source of chaos I accidentally released" situations - some day will come to the conclusion that TDD is a very attractive way to build the code.
I agree with the general pointlessness of unit tests. So what if you function returns "Bananas" every time you call it.
Automated UAT. Now that's where it's at.