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!

The Unselfish Act of Writing Tests

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

####ORUG At this months Orlando Ruby User’s Group meeting, I did my Testing on Rails presentation. In it I touched on just some of the benefits of having an automated suite of Unit, Functional, and Integration tests.

!Benefits of Testing

Later I thought of another major benefit. Tests help other people on the project, in addition to the author of the test.

Good Habits are Contagious

Recently I had the opportunity to work on a project with Harris Reynolds. Harris did something very important that sadly, you don’t see on every Rails Project. He wrote a unit test. Lot’s of us wrote tests , but this particular test stood out for two reasons. The first was when it was written.

Writing Tests First

Harris had found a bug in a model object that I had created. To notify me, he checked in an assertion that failed, then emailed me. This saved me time searching thought and remembering code I had written. I simply typed rake test:recent which runs all recently changed tests in a Rails application . The error took me right to the problem, and I immediately fixed the bug.

Testing a Deployment

The second reason I remember this test happened at least a month later. The application was being deployed to a new machine, and the test failed. The particular model object being tested pointed to a different database that the rest of the application, and it turned out that that database hadn’t been installed correctly on the new machine. Harris’s test told the problem straight away, and saved time once again.

Unit Testing: the gift that keeps on giving.

Thanks Harris!