Imagine I'm starting today on a software system that I expect to spend
at least a year on. Being me, somewhere in the top five questions I
ask myself is "How am I going to test this?" Frequent automated testing
gives me confidence that I won't find out next week that today I broke
something that was working last week. Writing tests is also an important way
to organize my thinking about what I'm doing. Once I've spent time specifying
where I'm going, it's easier to get there quickly.
Since I'm going to be spending a year on this, it's worth my time to invest time
in tools and frameworks that will make specifying and running these tests easy.
I might even write some of my own.
However, suppose that I'm working on a quick demo that I'm only going to spend
a couple weeks on. Or a data-processing script that I need to have finished
tomorrow. Or a sysadmin task that I expect will only take half an hour?
In these cases, I still want the benefits of testing, but I want to spend
as little time as possible getting started. Also, it's not always clear
what technologies I'll be using: I may start in Java, and then find that
a Python library will give me 80% of what I need.
So, I've started to write start projects with test suites that consist of
nothing more than a bash script with a standard footer I copy-and-paste
from project to project. The advantages:
- Fast startup: I don't need to download anything or
run through any "new project" wizards. - If my project lasts longer than I expected, it's easy to remember how
to run the tests: just run the script. - I can easily refactor to use a more heavyweight framework like JUnit by
calling out to it from the script. - It isn't tied to any underlying implementation choice.
- Perhaps best of all, it rewards a UNIX style of small stdin-to-stdout
plug-and-play components.
With no further ado, here's an example script, this one drawn from
the JUnit build process:
