The Hand That Feeds
Ok so this is neither programming or politics, but I felt like writing about it anyways. I spent about an hour last night listening to the new Nine Inch Nails song, The Hand That Feeds. I bought it off iTunes (along with what I guess is the digital age equivalent of its B-side, The Line Begins To Blur.) NIN was my favorite band when I was in college, and I saw them and David Bowie in concert at the Forum in LA in 1996. It was one of the highlights of my years at Caltech :-) Anyways, the new song is awesome. I cannot wait until the new CD, With Teeth, is released on May 3. There's actually a listening party tonight at a club in San Francisco. If I was single and still living or working in SF, I would probably try to go, even though I'm not exactly a club guy.
Wednesday, March 30, 2005
Tuesday, March 29, 2005
More On Unit Testing
My JUnit presentation stirred some interest at my company. We are working on a lot of code that runs inside an application server. JUnit is not really meant for such apps, but there are extensions that are. The one that I pointed out in my presentation was Cactus. There were some other people touting JUnitEE today in email threads at work. Others quickly pointed out the many advantages Cactus has over JUnitEE, though I actually think other would probably be sufficient for testing EJB session beans, which is the most common thing we have to test. Cactus is better for web apps, and since we have a framework we've built for building web apps, it seems like a more logical choice.
My JUnit presentation stirred some interest at my company. We are working on a lot of code that runs inside an application server. JUnit is not really meant for such apps, but there are extensions that are. The one that I pointed out in my presentation was Cactus. There were some other people touting JUnitEE today in email threads at work. Others quickly pointed out the many advantages Cactus has over JUnitEE, though I actually think other would probably be sufficient for testing EJB session beans, which is the most common thing we have to test. Cactus is better for web apps, and since we have a framework we've built for building web apps, it seems like a more logical choice.
Unit Testing
Yesterday I made a presentation on JUnit and unit testing in general. I tried to make my presentation very informative, but it's really a pretty interesting topic. I think unit testing is one of the most misunderstood aspects of software engineering.
Most engineers resist the idea at first, and for good reason. It seems like a lot of overhead being added to the development process, and it's usually overhead that nobody is going to give them time for. I know that's the way it seemed to me when I was first introduced to unit testing. I started to change my mind on the subject because I was able to experiment with it first. Having a structured but easy-to-use framework for testing my code as a I developed it was great. As I became more and more familiar with it, and had the chance to teach others about it, I became more in-tune with the philosophies behind it and more rigorous in my approach.
I really became cognizant of the misconceptions about unit testing while I was working at KeepMedia. On one hand I had a manager who did not like the idea of introducing overhead, just as I had felt years before. On the other hand, we had a very understaffed QA staff, and they looked at developer written unit tests as a way to get quality building blocks for regression testing. Of course there are flaws with both of these mindsets.
Unit testing is overhead, but not necesarrily significant overhead if you use a framework like JUnit. Of course the more complex an application is, the more effort there will be in creating sufficient unit tests. A complex application needs more unit tests, though, and that's the point. Unit tests don't add as much overhead as you think because they help you catch a lot of bugs early on. So the extra time you spend early on writing unit tests will translate into less time later. It can also translate into less time during the QA cycle, which is a bonus since there are more people's time involved at that stage. The hard thing for inexperienced engineers and managers to understand is that bugs will happen, and that's what makes unit testing valuable (well there's other things too, but I won't get into that yet.) My manager at KeepMedia was inexperienced in managing software engineers, so this was not easy for him to understand.
Now I mentioned the QA cycle above and how unit testing can reduce that cycle in many cases. However, unit testing is not meant for QA, it is meant for developers. Of course functional testing by QA has a lot in common with unit testing, but QA should never use unit tests written by developers as a substitute for their own functional testing. JUnit (especially with Ant) makes the aggregating and automated running of unit tests very easy, and it can be tempting to leverage this for regression testing. This is an equally bad idea. I was actually surprised that QA people would want to do this, since you would think that they would see that such an approach would eventually eliminate a company's need for QA at all. If developers write all the unit tests that you need to perform functional and regression testing, then why do you need QA? Many XP pundits would actually say that you don't, but I think QA is still very valuable. I think they are valuable because of their objectivity, but you really lose that if they make use of unit tests written by developers.
Yesterday I made a presentation on JUnit and unit testing in general. I tried to make my presentation very informative, but it's really a pretty interesting topic. I think unit testing is one of the most misunderstood aspects of software engineering.
Most engineers resist the idea at first, and for good reason. It seems like a lot of overhead being added to the development process, and it's usually overhead that nobody is going to give them time for. I know that's the way it seemed to me when I was first introduced to unit testing. I started to change my mind on the subject because I was able to experiment with it first. Having a structured but easy-to-use framework for testing my code as a I developed it was great. As I became more and more familiar with it, and had the chance to teach others about it, I became more in-tune with the philosophies behind it and more rigorous in my approach.
I really became cognizant of the misconceptions about unit testing while I was working at KeepMedia. On one hand I had a manager who did not like the idea of introducing overhead, just as I had felt years before. On the other hand, we had a very understaffed QA staff, and they looked at developer written unit tests as a way to get quality building blocks for regression testing. Of course there are flaws with both of these mindsets.
Unit testing is overhead, but not necesarrily significant overhead if you use a framework like JUnit. Of course the more complex an application is, the more effort there will be in creating sufficient unit tests. A complex application needs more unit tests, though, and that's the point. Unit tests don't add as much overhead as you think because they help you catch a lot of bugs early on. So the extra time you spend early on writing unit tests will translate into less time later. It can also translate into less time during the QA cycle, which is a bonus since there are more people's time involved at that stage. The hard thing for inexperienced engineers and managers to understand is that bugs will happen, and that's what makes unit testing valuable (well there's other things too, but I won't get into that yet.) My manager at KeepMedia was inexperienced in managing software engineers, so this was not easy for him to understand.
Now I mentioned the QA cycle above and how unit testing can reduce that cycle in many cases. However, unit testing is not meant for QA, it is meant for developers. Of course functional testing by QA has a lot in common with unit testing, but QA should never use unit tests written by developers as a substitute for their own functional testing. JUnit (especially with Ant) makes the aggregating and automated running of unit tests very easy, and it can be tempting to leverage this for regression testing. This is an equally bad idea. I was actually surprised that QA people would want to do this, since you would think that they would see that such an approach would eventually eliminate a company's need for QA at all. If developers write all the unit tests that you need to perform functional and regression testing, then why do you need QA? Many XP pundits would actually say that you don't, but I think QA is still very valuable. I think they are valuable because of their objectivity, but you really lose that if they make use of unit tests written by developers.
Monday, March 28, 2005
This is my second try at a blog. My first was back in 2003, while my wife was pregnant with our first child. Of course becoming a dad took a lot of my time and the blog went down the drain. Now our son is a year old, and I have a little more time. This time I'm going to stick to non-personal stuff, mostly technical and political. I'll try not to mix the two, since the technical ones may be reposted on my company's intranet. So let's start with a political one.
The Terry Schiavo ordeal has really gotten out of hand. It's amazing that Republicans have been so willing to try and step in to an affair that was legal one handled by a state court. Of course nobody wants to have to make the decision of letting a love one die, but would it really be better to have the government make this decision for us?
Even more annoyingly predictable is the anti-judicial system banter. I had to hear a pundit on CBS radio last night talking about how wrong it is to let unelected judges make important decisions like this, instead of having our elected officials do so. This is usually the kind of talk you hear when the courts protect flag burning or don't allow prayer in public school.
Of course liberals are just as bad. I'm constantly getting bombarded by emails from liberal groups about trying to block Republican appointed judges. Maybe the judicial branch always winds up being hated? I guess that makes sense because they are not elected and don't have to worry about re-election. If they were elected, then we would just have to blame ourselves for electing them but could vow that they would not be re-elected.
The Terry Schiavo ordeal has really gotten out of hand. It's amazing that Republicans have been so willing to try and step in to an affair that was legal one handled by a state court. Of course nobody wants to have to make the decision of letting a love one die, but would it really be better to have the government make this decision for us?
Even more annoyingly predictable is the anti-judicial system banter. I had to hear a pundit on CBS radio last night talking about how wrong it is to let unelected judges make important decisions like this, instead of having our elected officials do so. This is usually the kind of talk you hear when the courts protect flag burning or don't allow prayer in public school.
Of course liberals are just as bad. I'm constantly getting bombarded by emails from liberal groups about trying to block Republican appointed judges. Maybe the judicial branch always winds up being hated? I guess that makes sense because they are not elected and don't have to worry about re-election. If they were elected, then we would just have to blame ourselves for electing them but could vow that they would not be re-elected.