Testing Like Rails

One of my main goals in this project was to be able to do full lifecycle testing on objects I’m using and to get pretty close to test driven development.  I realize there are some good reasons to mock data and not use the database, but in my case, I want to do so in order to create some scenarios that can later be used for demo purposes, and I have some values that are database-generated that I want to test.  If we can keep ourselves honest by creating cases that are good enough to demo, then we should be doing a pretty good job of covering the system.  Of course, there are some tests that don’t fit this profile — testing that a partial save of a hierarchy intentionally fails, etc., but most are a great fit.  So, what I wanted was to have a test database separate from production and dev but not have to keep up with SPs and schemas.  Here’s how it works:

Testing the UI

In my web.config, I’ve got connections for Dev and Test.  In my Unit tests, I’ve got an app.config pointing to a local test database (I’ll add a demo database later). Following the rails model, there are methods for creating an entity — things like “TheJonesFamily” that are static and return an entity.  These get used throughout all the tests.  I categorize my tests as follows:

• Model tests – building blocks for testing models and combinations of models (ModelTest)
• Direct insertion of data and verification of data in the database (DirectDataTest)
• Controller tests for create actions (UICreateTest)
• Controller tests for view (show) actions (UIViewTest)
• Demo tests – these are the tests that are used in building the demo data (DemoTest)

I’m using Migrator.net, so I’ve got separate proj files for dev and test.  One of the nice things is that in some of my tests, I’ve got TearDowns that reset the database, essentially migrate down then back (also a nice double-check that the migrations are in good shape both up and down the chain).  But I can keep whatever data is lying around in my dev db without any impacts.  This also lets me run MSBuild (to move to NAnt later) to update my demo site by running the tests with that category.  So, in one step, I update the system, test it, and load demo data.  Much happy.  Obviously, things are a little more complex for production, but that’ll be another post.

At the end of the day, I’m on my way to a very usable infrastructure for development — the cycle is this (so far):

• Create migrations
• Run the PLINQO Codesmith Templates (with some modifications I’ve made) to generate the DBML, update the generated entities, and update the managers
• Update unit test entities (essentially stubs that can be saved to the database — mocks will get used later for external services, etc.)
• Update unit tests for the models, controllers, and views
• Update logic in the models, controllers, and views
• Test

It ain’t perfect, but it’s a heckuva lot better than what I would have done if I hadn’t met Rails.