tags:

views:

355

answers:

9

I'm not a newbie since I've been programming on and off since 1983, but I only have real experience with scripting languages like Applescript, ARexx, HyperTalk and Bash.

I write scripts to automate data entry, batch process images and convert file formats. I dabble at Processing, Ruby and Python.

Most of the programs I write are under 200 lines with at most 10 functions. I wish to write larger, more capable programs in the future. I want to improve my practices to avoid creating fragile, unmaintainable messes. The programming environments that I work in (Script Editor.app and Text Wrangler.app) have no support for automated testing.

At the scale that I'm working now and writing procedural (not OO) code, is it appropriate to write unit tests, which I understand are:

short programs to test individual functions before combining them into a fully functioning larger program.

Are unit tests worthwhile compared to their cost when making programs at this scale?

+1  A: 

If the code logically is divisible into smaller units, then unit tests are appropriate. If the code cannot be sensibly divided into smaller components, then it's a single unit, and I would argue that in that case automated unit testing and automated functional testing would be indistinguishable.

Daniel Papasian
Is that just your way of saying "always use unit tests no matter what"?
willc2
+2  A: 

totally, you'll know you are not breaking any existing features while adding new ones in a couple of months....

just one of the many plus-value of having a set of test for a piece of code.

pmlarocque
+7  A: 

Yes. Anything longer than zero lines can be unit tested - usually to good effect.

Jonathan Leffler
Certainly anything CAN be unit tested. Is it ALWAYS appropriate to create unit tests?
willc2
The only case I can think of where unit testing would not be appropriate is a one-off program that will be run once to do something specific and then be thrown away. Then again, even those have a way of hanging around and evolving into something generally useful.
Ferruccio
Check out the (possibly apocryphal) history of IEFBR14 at http://en.wikipedia.org/wiki/IEFBR14
Jonathan Leffler
+4  A: 

I'd look at the likelihood for regressions, not the number of lines of code. If your programs will live a long time and are likely to be refactored or otherwise modified, then unit test may make sense. If the code is throwaway or never likely to be modified, then unit tests probably won't be worthwhile.

C. Dragon 76
+1  A: 

Definitely beneficial as writing the tests may help verify the design of your functions (does the API make sense) and helps protected you from mistakes in the in the future. Unit tests can also act as a contract for your functions which can indicate how the functions should be used and what they expect.

With shorter programs that are clear simply by reading the code it may not be beneficial to thoroughly test it if you do not have alot of time. Otherwise I have to agree with my colleagues here that unit testing has a variety of benefits and is helpful for even for small projects.

Warning: The following links may not be applicable but the ensuing discussion is a good read.

There has been some discussion recently within the blogosphere as to when testing is appropriate, specifically Test Driven Development (TDD). You might want to check out some of the articles such as these three articles by Roy Osherove.

smaclell
A: 

The only time you need to write unit tests is when you care that the output of your program is correct, and will continue to be correct in the future.

If correctness of your code is not important, then it is not necessary to unit test.

Andy Lester
I test my functions by putting in expected types of data, then checking for correct output. What is the difference between that and unit testing?
willc2
Almost none. Just make sure you also test how it reacts to invalid input data as well.
Milan Babuškov
Unit testing lets you check that it still works later on, not just when you write it. It also guarantees, to some extent, to other users that you did test this.
Kena
+3  A: 

Unit tests serve a couple of purposes; the most obvious is to test the code to determine that it's doing what it's supposed to do. But one of the other, more useful purposes, is implicit documentation; if you explicitly unit test a piece of code for a specific behavior, it becomes clear that that behavior is anticipated, even if nonobvious.

Consider the humble addition operator. Straightforward, right? Well, what's the expected behavior when adding two signed integers, both of which are > than MAXINT / 2? Is it MAXINT, or is it a negative number?

Documenting all this stuff can be unwieldy, at times; not to say that it shouldn't be done, but experience shows that it frequently doesn't get done. However, an explicit unit test that tests for the above case being negative removes all doubt; as well as serving a valid purpose for regression, that the behavior hasn't changed over time.

McWafflestix
+3  A: 

Today it's a small project, tomorrow it's the centerpiece to your corporate infrastructure. Start it out right, get 100% code coverage right away.

justin.m.chase
A: 

I must digress with most answers. Donald Knuth once said in an interview that people tend to test most things when they are unsure of what they are doing or are working in a not-so-comfortable domain.

With that in mind, I say that besides documenting like mcwafflestixlivejournalcom said, unit tests only help you if you are not 100% sure of your code. Taking the example of the addition operator for two ints, I don't care about the overflow if I'm adding two person's ages.

OTOH, unit tests makes you factor out the core logic of your programs (which makes you do things more modular) and helps you test faster than you could ever do if you were testing 'manually'. Not all of us are Donald Knuth after all.

Bear in mind that my answer is for small functionality, like the original poster asked

Miguel Ping