Testing a Non-Rails Application Using Rails

2007-03-31T13:11:00+00:00

Rails developers working on enterprise software projects are suprised to discover the lack of automated tests in many mature web applications. As frustrating as this can be, A lack of automated tests is also a tremendous opportunity to

1. Learn your non-rails applications underlying database structure.
2. Demonstrate to a devlopment team the power of The Rails Framework.
2. Encourage automated testing.

Rails may be the quickest path to automate some basic test of your non-rails applications data model. These steps will get you all set up to write your automated tests in Ruby.

1. Connect to Your Enterprise Database 2. Set DB Conventions 3. Safety Net 4. Duplicate the Schema 4. Extract Development Data

I. Connect to Your Enterprise Database from Rails.

Download and install any os driver, ruby gems, and rails adapters needed to connect to your database:

MySQL
DB2
Oracle
Sybase
SQLServer
PostgreSQL
Firebird

II. Set Your Existing Database Conventions

, Recipie #16 can walk you through this very quickly.

Identify any conventions used by your legacy database. Application wide conventions can be set in the config/environment.rb file. They are specified by calling the appropriate class methods available on ActiveRecord::Base. The methods you need to call depend on how your database is configured:

ActiveRecord::Base.table_name_prefix 'myapp_'
ActiveRecord::Base.table_name_suffix = '_def'
ActiveRecord::Base.sequence_name = 'dev_company'
ActiveRecord::Base.pluralize_table_names = false 
ActiveRecord::Base.primary_key_prefix_type = :table_name_with_underscore # or :table_name

III. Safety Net

Load the SafetyNet Plugin into your rails app to prevent from destroying your development database.

IV. Duplicate Your Database Schema

OK , with your dev and test development databases set correctly, let’s try duplicting the schema.

rake db:test:clone If this works right off the bat, you’re one of the lucky ones. Skip to Extracting Development Data

If you recieved errors from the clone command, do steps A through C .

A. You can now correct any errors you may have had by manually modifying schema.rb . See Oracle Errors for some problems I had with the Oracle Database. Since schema.rb is generated, it’s a good idea to rename it when you modify it manually.

B. The clone command above may have started loading data; you need may to purge the test db.


rake db:test:purge

C. Tell rake to load your new schema file by passing the new name, relative to RAILS_ROOT in the SCHEMA environment variable:


rake db:schema:load RAILS_ENV=test SCHEMA=db/oracle\_schema.rb

V. Extracting Development Data

Copy the code from Rails Recipe #42: extract_fixtures.rake to your RAILS\_ROOT/lib/tasks directory.

TIP: If your develoment database has lots of data, Modify the SQL Select in this code to limit the amount of data you copy using the SQL limit statement:

sql = "SELECT * FROM %s limit = 100"

Or for a proprietary database, the equivalent command:

sql = "SELECT * FROM %s WHERE ROWNUM<=100"

Then run


 rake extract_fixtures

You’ve made your testbed so you can lie in it.

You now have and exact copy of your development database, and a collection of sample data in Yaml format, and are ready to begin writing some Unit Tests. Stay tuned for some examples. Rail on!

Rails SafetyNet

2007-02-07T21:14:00+00:00

Curent Mood: Bored with Deleting the Production Database

I thought I was the only clown working on Rails projects and ignoring the warning in config/database.yml and using rake to wipe out perfectly good databases. But I’ve seen it happen to others now, and enough’s enough. So I created the

SafetyNet Plugin

You can install Safety Net in your app, by running


ruby script/plugin install svn://rubyforge.org/var/svn/apptrain/trunk/vendor/plugins/safety_net

That’s it. Now, If the test database points to the same database as development or production running rake will display the following message:

!safety net

rake aborted! 

The name of your test database matches production or development.

How it Works

Purging the poor innocent database is prevented in two ways.

1. By adding a prerequisite check to the rake script that normaly performs this task. 2. By modifying the fixtures method on ActiveRecord to avoid the same fate when running individual tests with the ruby command.

Martinicity: Tag rake