Unit Testing or, as J.B. Rainsberger likes to refer to it, Programmer Testing is a seriously undervalued and underused technique within the I.S. industry. I just read a post by Andrew Binstock over at his personal blog asking "Is the popularity of unit tests waning?" This is an interesting question.
I also found interesting, his observation that TestNG is effectively invisible. For the record, I had not only heard of it, but was previously asked to be one of the pre-press technical reviewers for the book. But, it is true that when you speak of unit testing these days you are, by default, referring to JUnit.
But back to the question. As I ponder this, I am drawn to the conclusion that it never was popular. Unit testing is pretty much the programming equivalent of flossing your teeth. You know you should do it and you understand the health benefits that will come from it, but you just never quite manage to get yourself to do it.
I think that unit testing has been promoted by the alpha geeks and early adopters of tools and techniques. I have been using it more on than off for over five years now, so I can honestly tell you that getting programmers to write unit tests is seriously hard work. I have had the most success with my JUnit evangelism with teams that I am personally leading. As a technical lead, I try to lead my teams by example and show how unit tests help me be certain that my code does what I think it does and how it is safe to refactor because I can prove it works with a simple run of an ant build.
I have had a moderate amount of success with management. Most managers now recognize the term unit test and they will generally agree that they are good things and that programmers should indeed write them. The problem comes when the deadlines get short, because so do their memories and they "forget" that they agreed that unit tests should be written no matter what, even if that means an overrun on the targeted due date. All hail the great god Deadlines!
I have had so little success convincing fellow programmers to use unit testing that I'm almost embarrassed. I was even the "JUnit sheriff" at a previous location and I still didn't get much traction. I think that the problem comes from the lack of positive feedback. Knowing that you get more of the behavior that is rewarded, the lack of unit testing must be because of the lack of seeing unit testing produce positive results.
On previous projects of mine, thinking especially of a big one a couple of employers back, I have insisted on unit tests (writing them myself where necessary) and the positive feedback loop starts to kick in and the others on the project start writing them as well. At the current employer, there were zero unit tests in the house when I walked through the door just over a year ago. I was involved in a couple of projects where I wrote unit tests, but after they got canceled, the positive feedback loop was short-circuited and we are still having an awful job getting folks to write tests.
If you haven't seen a suite of unit tests working its magic and saving you from certain crashing, then it's hard to internalize why you would want them.
So, one of life's great dilemmas. Unit tests are good for you, but until you see them work, it's hard to see that they could work.
I also found interesting, his observation that TestNG is effectively invisible. For the record, I had not only heard of it, but was previously asked to be one of the pre-press technical reviewers for the book. But, it is true that when you speak of unit testing these days you are, by default, referring to JUnit.
But back to the question. As I ponder this, I am drawn to the conclusion that it never was popular. Unit testing is pretty much the programming equivalent of flossing your teeth. You know you should do it and you understand the health benefits that will come from it, but you just never quite manage to get yourself to do it.
I think that unit testing has been promoted by the alpha geeks and early adopters of tools and techniques. I have been using it more on than off for over five years now, so I can honestly tell you that getting programmers to write unit tests is seriously hard work. I have had the most success with my JUnit evangelism with teams that I am personally leading. As a technical lead, I try to lead my teams by example and show how unit tests help me be certain that my code does what I think it does and how it is safe to refactor because I can prove it works with a simple run of an ant build.
I have had a moderate amount of success with management. Most managers now recognize the term unit test and they will generally agree that they are good things and that programmers should indeed write them. The problem comes when the deadlines get short, because so do their memories and they "forget" that they agreed that unit tests should be written no matter what, even if that means an overrun on the targeted due date. All hail the great god Deadlines!
I have had so little success convincing fellow programmers to use unit testing that I'm almost embarrassed. I was even the "JUnit sheriff" at a previous location and I still didn't get much traction. I think that the problem comes from the lack of positive feedback. Knowing that you get more of the behavior that is rewarded, the lack of unit testing must be because of the lack of seeing unit testing produce positive results.
On previous projects of mine, thinking especially of a big one a couple of employers back, I have insisted on unit tests (writing them myself where necessary) and the positive feedback loop starts to kick in and the others on the project start writing them as well. At the current employer, there were zero unit tests in the house when I walked through the door just over a year ago. I was involved in a couple of projects where I wrote unit tests, but after they got canceled, the positive feedback loop was short-circuited and we are still having an awful job getting folks to write tests.
If you haven't seen a suite of unit tests working its magic and saving you from certain crashing, then it's hard to internalize why you would want them.
So, one of life's great dilemmas. Unit tests are good for you, but until you see them work, it's hard to see that they could work.
1 comment:
I have seen such an increase in the number of people writing tests and even practising test-driven development, so it is a surprise to read that unit testing is still so uncommon. When I think about it for a few moments, it's not so surprising.
If your team is not seeing the benefit from writing their own tests, then perhaps your team isn't writing tests at the most opportune time. Generally speaking, when teams adopt the rule "write failing tests for each defect before trying to fix it" they tend to see the benefits of writing their own tests more clearly, so that might help.
So if your team is writing all these tests and not seeing the benefit, what tests are they writing, and when, and why isn't your defect rate declining, and why isn't the time it takes to fix defects declining? I'd certainly want to do some root-cause analysis on that.
Take care.
Post a Comment