It seems that too often I write code to get it to do what I want and then move on to the next bit of programming. This works great until it doesn't. So how do we take care of those times where it doesn't? We use unit testing. It is necessary tool and should be used by everyone, but it is time consuming and kind of boring.
If you haven't used unit testing before it is a series of tests you create to make your program fail. If you pass all these failing tests you don't win anything other than the joys of having to think of more ways to break your program and write even more tests. I feel that for every line of code you write, plan for about 3 million tests (this number is a dramatization). It might not really be that bad however it is tedious.
To alleviate some of this pain though there is a thing for us crazy C++ programmers called Cxxtest. It is a good way to actually test your C++ coding. You write you're testing in a header file using some basic calls such as TS_ASSERT, verifying things are doing what they are meant to do. You compile it and it does all the grunt work is done behind the scenes, it's a really nice implementation.
Unit testing might help as long as it's used properly. You do have to make sure to take small steps in writing your tests or you can miss an earlier problem. For example, during the development of getting a scanner program to work with a given parser, my partner and I kept running into a problem which introduced logic identifiers such as equal to and not equal to. After many aggravating hours of banging our heads on desks and daydreaming of going all Office Space on the system we discovered that it was actually a problem with variable names. We hadn't accounted for variable names with integers. So our test was failing because we had taken two steps in one test. It was a lesson well learned.
My problem actually was found using unit testing. Granted I wasn't looking for that problem with that specific test but it did get found. This experience alone helped me understand why testing is important and why it is also a pain.
Unit testing...*yawn*
No TrackBacks
TrackBack URL: http://blog.lib.umn.edu/cgi-bin/mt-tb.cgi/166740
I agree with your opinion on testing. It is tedious, long and horrible. But it must be done. And it (if done correctly) will save time in the long run.
I agree that as glamorous and exciting being a programmer can be, it definitely has its dull and boring parts to it. Testing is one of them. Like in a lot of things though, it's these dull and boring bits that end up being the most important. CxxTest is nice in that it automates at least a part of the testing process for us.
-Nathan Dowd
I guess testing your code is like "Why should I bother with Unit Testing?" article says: Everyone knows that eat broccoli is healthy, but not every one is willing to eat it, so writing tests for our code is more a right thing to do than a common practice.
Javier Ayala
My partner and I had a similar situation where we forgot to put a "." in our string regex and it was unit testing that rescued us. Unit testing may not be all "fun and sexy" but it sure is helpful in tracking down bugs you didn't even know you had.
Sam Barris
I agree that unit testing can be a tedious procedure, but powerful if used correctly. I too had a couple problems with unit testing almost ending in an Office Space-like meltdown, but it involved not naming our tests with the word "Test" in front of them.
Cxxtest does help make testing a little easier because unlike Java IDEs such as Eclipse, testing tools are not so easily integrated all in one application. My partner and I didn't write any tests, instead we just compared our outputs to the expected outputs and, in a sense, that was how we "tested" our code. That was of course after tedious hours of trying to compile our program.
- Keng Kue Lor
I think most of us are just anxious to get the coding finished which makes unit testing a boring yet necessary distraction. Thinking of ways to break our code can also be tedious, but it makes our code much more robust.
Brett Bedeaux
Maybe my unique approach to "pain" in software development will help you. Instead of labeling a very pragmatic task like unit testing as boring (though I'll admit it is), remind yourself that it is saving you not only hours of bug-searching and rewriting, but also that dull, nagging stress that constantly reminds you that the massive block of code you just powered out only *might* work. Much like in Berry's "The Inevitable Pain of Software Development", diligent testing is a simple and very effective way to avoid the "avalanche skiing" mentality. Instead of saying that it's the "diligent" thing to do, though, I just say that I'm lazy and want to avoid all that extra stress and work!