Markjuh

Today I’ve been explaining some basics of Ruby on Rails to a friend of mine. With a couple of friends we’re building a front-end for LEDR, which is basically an educational document repository, which we intend to use at Eindhoven University of Technology.

We only went into the model part of the MVC design pattern. And since Rails applications are especially suited for Test Driven Development, I decided to start showing Rails by writing unit tests. So we first started with the generation of a model and then wrote some basic CRUD tests for them. We had been writing down requirements for some of our models earlier today and could now write these requirements in the tests directly. We heavily borrowed test code from other projects I’m doing. So we had some default tests for each possible model requirement we had come up with.

Time to run rake! And boy, did we get failures and errors!

We were using SQLite, had created the databases and even made sure config/database.yml contained the right settings. All nice, but we had forgotten to install sqlite-ruby on our development system. (Ironically enough, our production server already has it installed.) We should have definitely read Howto Use SQLite in Rails a bit better.

If you are not even interested in writing tests, running the automatically generated test for the model would have already shown this.

After getting this out of the way, our tests were still failing… Well, duh! We forgot to even create a table in the database for the model. Again, just running the automatically generated test would have shown this.

So, writing the table and importing it in SQLite (which by the way is a painful process when you are used to PHPMyAdmin or YourSQL for all your database editing) solved at least a bunch of the errors/failures. Basic CRUD tests were now at least passing.

So on with the more interesting aspects. Our tests clearly showed we were missing validates_presence_of, validates_uniqueness_of and validates_format_of. Since we had some well-defined tests, it was really clear what to add in the corresponding model.

Still, one test was failing… The test that made sure that we couldn’t change the code field of the model. Maybe not as clear, but after some thinking we added the following straightforward before_update to the model:

  def check_code_changed
    Course.find(id).code == code
  end

Now our test should have all passed.

Unfortunately there is a bug in Rails I wrote about some time ago. So we first had to apply the patch I had made for the bug. Then everything worked just fine.

After this we wrote another two models and created relationships between them, all driven by tests defined before actually writing any model code. And every since test-case that failed showed us exactly where we had to find the problem and showed us at least a hint of where to find our mistakes or where to add model code; even more specific, it often showed us which code to add.

We also had a problem in the SQL code that updated our SQLite database. It wasn’t actually a query performed by Rails, but we needed it to update our table to the lastest version. We had totally forgotten to add a commit at the end of the transaction. Our tests showed our missing field in the table quite nicely.

I can conclude that it convinced us both that Test Driven Development is the way to go when developing Rails applications. It helps you detect so many things, sometimes not even directly related to the specific model (as we can see above). Lots of times before I had seen tests as a necessary evil, but today we both got really excited by writing tests and seeing all the positive results we got from it. Our tests even made it possible to write Rails code after having a couple of glasses of wine. ;)