Yikes, last week I was too busy working/in-meetings to squeeze in a blog post, so I’ll post a quick one to start of this week.

Since I’ve taken the plunge into developing a test suite for all of my new rails applications (most notable Concerto 2), I’ve struggled with the testing work flow.  Its very natural for me to write a piece of code, refresh my browser, verify the results, and repeat the cycle until I get it right.  The more official testing strategy requires me to write a test + the actual code and make sure the two of them mesh up before I even bother to refresh my browser.

Starting this process was a bit hard for me, probably because my test-writing skills weren’t so hot.  Many times my `rake test` results were failing not because there was an actual bug in my application code, but there was a bug in my testing code.  Unlike the application code which can be viewed in a browser, there really isn’t any way to know if your test is running as expected, so you really have to keep things as simple and straightforward as possible.

If you’re going to be developing in Ruby on Rails and using tests for your application, I’ve found a few tools that help out a lot:

• autotest – Autotest is a tool that automatically runs the relevant portion of your test suite as you save files.  Essentially, when you save the file foo.rb autotest will automatically run the tests it thinks are related to foo.rb and nothing more.  In rails land, this saves a lot of time waiting for tests to run that are unaffected by a small or incremental change.  You can install some cool plugins to make the output red or green or use growl notifiers if you want… I just use the red/green plugin to spice up my terminals
• CI Joe – CI Joe is a really simple continuous integration server.  A continuous integration server (automatic testing server) doesn’t make a whole lot of sense for single developer projects, but as more people are contributing and committing code it helps to have an automated system that is making sure the latest commit doesn’t break any tests.  I set this up for Concerto 2 development so everyone on the development team can quickly see if the HEAD is broken or not without having to ssh somewhere, git pull, and rake test on their own.

My one cautionary word about testing: don’t dive in too deeply.  It makes sense to develop really well formed test cases for critical portions of your application or code that is constantly being changed, but I’m not sure there is value in developing 12 tests to validate every possible form input and exact error message wording… at some point your time is better spent developing the application instead of supporting tests.