This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: There's no substitute for general futzing
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
Do I write unit tests? Sure I do - I'm a good boy. I do the best I can to make them good unit tests, too.
However, no number of unit tests substitutes for general futzing. And by "general futzing" I mean writing little sample programs. You see, I'm the sort of person that has to see to believe. I just can't bring myself to put 100% faith in unit tests, no matter what.
You'll notice that about me if you download any of my packages. They all have an "examples" directory where there are little sample scripts you can run. These are what I use in addition to unit tests to make sure things are absolutely, positively working the way they should.
Sometimes this catches bugs I would not have caught with a unit test. Take today, for example. I was playing around with the Admin.get_group method. It passed all its tests, but something wasn't right. The group ID being returned seemed wonky. Did the method work? Yep. Did the group ID come back as a number? Yep. Did all of the other attributes look correct? Yep. So, what was wrong?
It turned out that I had inadvertantly forgot to convert a VALUE to an integer. However, the compiler didn't complain. Neither did Ruby. It just turned it into some wonky number on its own. Would I have caught that with a unit test. Nope. No way. And, even after knowing about this error, I still couldn't write a meaningful error test for it.
Another reason I like sample programs is that they're a good way to learn an API very, very quickly. Often times you don't feel like wading through what could be several pages of documentation just to figure out how to do a single thing. You just want to perform a specific task, and you want to do it NOW. In this way, a sample program serves as a sort of living FAQ.
The final reason I write sample code is to help me flesh out the API. I sometimes write sample code before I've written the underlying library. This, in a sense, forces me to eat my own dog food. It makes me think about how I would like to use the code. It's a good way to detect if your code is overwrought or excessively verbose.
So, the moral of the story is: be sure to engage in general futzing. Oh, and drink your Ovaltine, too.
Previous Topic
