Note: This post is a work in progress.

My first impression of the Rails testing framework was that it is the shit. Unfortunately I haven't been able to get it to work yet--my preferred database configuration is not supported by Rails/ActiveRecord. The configuration that I would prefer to use is not far outside of the norm by most standards; I simply want to have a single database with multiple schemas for test, devel and production, as opposed to Rails' preferred method of using three separate databases.

Something else that's irksome is Migration's lack of built-in support for unique and foreign key constraints, and sequences, outside of execute statements. It's easy enough to use raw SQL for those things, but it seems to make using Migration a moot point; it's easy enough to use the up/down database versioning with raw SQL files, I have been doing it for years.

Another issue that I ran into, is that ActiveRecord abstracts so much of the database interaction that simple things like rolling back a transaction might as well be impossible to find for a n00b like myself; I searched for an hour and decided to move on with a reconnect statement and TODO comment. In fact, I never even found documentation for how to deal with a constraint violation at all. I took my prior knowledge of Java and figured I could "rescue" the StatementInvalid error; but again, no mention of how to handle the connection.

Beyond those issues, testing has been pleasant. I created a simple registration controller that displays a form and handles its submission. I am able to verify the registration by doing a find on ActiveRecord. I am also able to easily test validation errors and cases such as "username already exists" (enforced by a database constraint)--two things which almost no applications I have developed have ever been tested for--save for HealthMatch. It is interesting to work with the Rails testing framework because the level of coverage possible mirrors the goal of ongoing effort on that project. Just last week I created a prototype DbUnit-enabled validation test base with an identical concept of fixtures, so I will be able to take a lot of this experience back there.

The main argument I've had against Rails (and PHP, and ...) is that dynamic languages in the context of a medium-scale, medium-lived project will face brutal regression issues. I hope that the testing framework lives up to my expectations and provides a level of coverage that makes my argument moot. The defective nature of Rails' pre-5.x MySQL-centric database support is annoying, but it isn't a deal breaker. It did, however, smudge up the glossy image I had of Rails after the reading about its testing framework I've done lately, which was total redemption in my eyes.

Source code for my demo is available in trac and directly from the subversion repository.