This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with the introduction and overview of the ideas behind testing.

Now that we have unit tests to insure that our models are related properly, we are ready to test our the validations in our models.

There are two approaches to testing your validations. It will be useful to examine both techniques because it will help you to write better tests overall. First, we need to write tests that confirm the code we have in place is working properly—as we have done thus far. Second, we need to think about special cases that we might not have coded into our validations already. This is where writing tests can really improve your code, and validations are a great place to see it in action.

(more…)

Sun Microsystems has purchased MySQL for $1 billion dollars. That sounds like a lot of money but. considering the popularity of MySQL, I think it was a bargain for Sun.

What does the purchase mean for developers? Nothing yet.

It’s as if your favorite restaurant just got a new head chef but the menu is the same. Some of the dishes may change slightly over time—you might not notice. Someday the chef may decide to make more radical changes, even revise the whole menu. Changes to the kitchen operations and to the food may improve the quality and service of the restaurant, or it could hurt it. But for the near future, you can still order your favorite dish, pretty much the way you’ve always had it.

This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with the introduction and overview of the ideas behind testing.

Unit Testing ActiveRecord

In the unit tests we wrote previously, we tested everything in the class. The rule of thumb was that everything needs to be tested. That has not changed now that we are working with ActiveRecord—each method still needs a test.

But what testing should be done on the basic database CRUD (Create, Read, Update, Delete)? After all, that is what is most different about classes that inherit from ActiveRecord, right? It may surprise you to learn that we do not need to test basic CRUD.

Why not? ActiveRecord handles all of our database activity for us. It knows how to connect to the database, how to create, find, read, update, delete, use conditions and sort. That is the reason why we are using a framework like Rails to begin with: because we can inherit all that ActiveRecord goodness without having to rewrite it ourselves. We can trust that ActiveRecord will do its job correctly.

photo by Tomás Castelazo

That is not blind trust—ActiveRecord has its own unit tests that the core Rails team uses to insure that it works properly. Therefore we can assume that everything our class inherits from ActiveRecord is solid and tested. It was unit tested before we installed it. We just need to focus on our code in the subclass.

The corollary to “Test Everything” is: “If it is code you added, it is code you need to test.”

(more…)