From: Phlip <phlip2005@...>
Date: 2009-01-12T00:19:34+09:00
Subject: Re: reccommended work flow for unit tests and databases in ruby

Adam Akhtar wrote:

> How does one go around creating unit tests for database tables during
> developement. Is there a rock solid work flow plan that everyone uses.

A myth of software development is you can plan out and invent your database 
schema before writing your code. This myth is so pervasive that some communities 
(>cough< Oracle) actively prevent programmers from changing their schemas.

Refactoring databases is a Best Practice, and all projects should include 
support scripts that overcome our database platform limitations.

> Im new to dbs and relatively so with unit tests. I have my project and
> it usually starts with a rough idea of what fields need to be in the
> table. As i code away items in the db change so it makes it difficult to
> write unit tests that will withstand these changes.

Investigate (and use!) the ActiveRecord system exemplified in Rails fixtures and 
migrations. When your program starts, only only _only_ put in the database the 
very few fields you are actually using. Rails's "script/generate model" will 
write a migration which adds that table to the db. Write tests for the model's 
behavior, and these will require fields in the table. Edit the model's migration 
file to add them. Repeat in tiny cycles, testing and integrating as often as 
possible. Never integrate if the tests break - revert if necessary. (This is 
more efficient than debugging!)

> I know i need a test version of a database with static items but what id
> like to do is for this test version to always reflect whats happening in
> the development one. So if I add a field in the development one, the
> test one gets one too.

Put sample data into the fixture files, and use it in the tests. Your scripts 
should then be able to migrate your test, development, and production databases 
in lockstep.

If you are not writing a Rails project, research how to get all these benefits 
without its framework. Rails can import fixture data into the development 
database with 'rake db:migrate'.

When you deploy to a live site, at this point stop editing your initial 
migration files, and only add new files that add and adjust your fields.

> I could just go and code this and probably get something that works but
> is probably ugly. I dont like to reinvent the wheel, a bad one at that
> so if anyone has some tips or pointers in the right direction id really
> appreciate it.
> 
> This is for small projects so it doesnt have to industrial strength
> bullet proof ninja stuff, small but elegant will be good enough

These techniques - after you spend a little time implementing them - keep 
potentially big projects very small and manageable. I would use them on projects 
of any size!

-- 
   Phlip