Writing software is all about managing constraints. If you’re the only developer on a project, you need a development process that can thrive despite limited developer resources. Users will inevitably scream out and you won’t always be able to answer immediately. Can you respond in such a way that they feel heard, even though you cannot immediately solve their problem? When you do respond, how do you ensure that you’ve got a solution that works, while spending as little time as necessary?
Fortunately, small projects can be incredibly agile. In the early days of JavaScript Lint, I would release a new version for every bug fix reported by a user, sometimes with an hour or two of the report. However, these releases also sometimes introduced regressions that should have been caught by testing, requiring more busywork to release another version.
About a month ago I started looking for inexpensive and unobtrusive ways to test JavaScript Lint. Originally, I anticipated adding complicated control comments to supress warnings. These control comments would themselves raise warnings if the expected warning wasn’t encountered. However, I finally decided that I’d be better off writing a simple Perl script (not an oxymoron!). This script easily lets me tweak configuration settings and check for specific warnings and errors in test scripts.
I’ve built up a collection of test cases for all the warnings implemented in JavaScript Lint, as well as for some warnings implemented in SpiderMonkey. When a user reports a bug, I can simply create a new test case and develop against it until it passes. I’ve been surprised how much this has increased my productivity in the little time I’ve devoted to JavaScript Lint in the last several weeks. The time spent writing automated tests has undoubtedly paid off already.
Now, if I only have a chance to clean up those release scripts, perhaps I can roll out a new version of JavaScript Lint!