Is unit testing doomed?(thestandard.com)
thestandard.com
Is unit testing doomed?
http://www.thestandard.com/news/2008/08/11/unit-testing-doomed
9 comments
I would not say so (and the article itself presents several compelling arguments) - developers & management just need to change their attitude a bit. Getting defensive about one's code is as old as "hello world" itself and once that is brought under control and the developer starts seeing the code as a "user" would - good unit test plans usually result. The benefits of unit-testing are easy to understand but difficult to quantify which is why management in its TTM focus tends to overlook it - you need a believer in the ranks to champion that cause. Fortunately there are plenty of those around so the questions / calls are a little premature.
you need a believer in the ranks to champion that cause
Nah, you need an entire project that is demonstrably better executed than another and that attributes its success to unit testing (or whatever). This is where evangelists fall down. They shouldn't preach until they've gotten something tangible to show.
Nah, you need an entire project that is demonstrably better executed than another and that attributes its success to unit testing (or whatever). This is where evangelists fall down. They shouldn't preach until they've gotten something tangible to show.
demonstrably
Not gonna happen. There are too many variables to control, and it's impossible to run the same project twice, let alone repeatedly. People with opposing beliefs will never be convinced by such a "demonstration"; they will simply find some detail or other to justify what they already believe.
The empirical literature on software projects is downright feeble. Meanwhile the programming culture is very rich in anecdotes and folklore. I find that suggestive.
Not gonna happen. There are too many variables to control, and it's impossible to run the same project twice, let alone repeatedly. People with opposing beliefs will never be convinced by such a "demonstration"; they will simply find some detail or other to justify what they already believe.
The empirical literature on software projects is downright feeble. Meanwhile the programming culture is very rich in anecdotes and folklore. I find that suggestive.
Yeah, it's funny, I mean say McDonalds their whole business hinges on how quickly they can cook burgers, but no-one there would ever consider under-cooking as a way to speed things up. So the average software project manager is not even as smart as the average burger flipper.
The advantages described by the author here are the same ones you always hear in discussions about the benefits of unit testing (bugs are caught sooner, you feel better about your code, etc.)
The real benefit to unit testing (at least from my experience) is that it encourages you to write better code up front. By thinking in terms of the smallest possible units, you don't bite off more than you can chew. As a results, your code tends to be more decoupled, more modular, and more logical (unit testing helps you organize responsibilities in your code).
For this reason, even if I had to delete every test I wrote after I made it pass, I'd still write a failing test before writing any implementation code. Of course I'd much rather prefer to keep my test suite, since it does provide the benefits discussed by the author. While no amount of unit tests will reveal every bug in your code, the quality of code I've written after writing a failing test first is vastly superior to code I've written sans-test.
Your mileage may vary, but if you haven't tried it yet, I suggest you give it a whirl.
The real benefit to unit testing (at least from my experience) is that it encourages you to write better code up front. By thinking in terms of the smallest possible units, you don't bite off more than you can chew. As a results, your code tends to be more decoupled, more modular, and more logical (unit testing helps you organize responsibilities in your code).
For this reason, even if I had to delete every test I wrote after I made it pass, I'd still write a failing test before writing any implementation code. Of course I'd much rather prefer to keep my test suite, since it does provide the benefits discussed by the author. While no amount of unit tests will reveal every bug in your code, the quality of code I've written after writing a failing test first is vastly superior to code I've written sans-test.
Your mileage may vary, but if you haven't tried it yet, I suggest you give it a whirl.
I'd be willing to bet that a class of problems caught by unit testing in Ruby/Python simply don't exist in Java due to its strong typing.
Of course the flipside of that is that Java's design patterns aren't nearly as important in Ruby/Python as they have functional programming capabilities out-of-the box. Swings and roundabouts.
Of course the flipside of that is that Java's design patterns aren't nearly as important in Ruby/Python as they have functional programming capabilities out-of-the box. Swings and roundabouts.
I'm semi new to unit testing, but I really like it so far.
I'm not sure if language choice effects need to unit test. I think that good unit tests test a lot more than type errors and although they are related to design patterns, in that design patterns allow easily unit testable code, and having unit tests in place allows easy refactoring.. unit tests would be helpful even if no standard design patterns were in use.
One main barrier to Unit testing that I have personally seen is that a lot of my work is GUI based or simple database CRUD applications. I haven't found a good useful way to unit test those.
I'm not sure if language choice effects need to unit test. I think that good unit tests test a lot more than type errors and although they are related to design patterns, in that design patterns allow easily unit testable code, and having unit tests in place allows easy refactoring.. unit tests would be helpful even if no standard design patterns were in use.
One main barrier to Unit testing that I have personally seen is that a lot of my work is GUI based or simple database CRUD applications. I haven't found a good useful way to unit test those.
"... I'd be willing to bet that a class of problems caught by unit testing in Ruby/Python simply don't exist in Java due to its strong typing. ..."
And I'd say an absence of errors does not mean no errors exist. While I don't advocate unit testing as a cure to defects it is comforting to make changes on a system and know you don't break something because of coverage.
And I'd say an absence of errors does not mean no errors exist. While I don't advocate unit testing as a cure to defects it is comforting to make changes on a system and know you don't break something because of coverage.
If your language is strongly typed and purely functional, a whole lot of stuff that is taken for granted these days (e.g. design patterns, unit testing) become a lot less prominent. People forget the Old Ways at their peril! :-)