Decoupling from Rails

Here is a great talk called Decoupling from Rails by the late Jim Weirich. This talk is most famous for being taken up by David Heinemeier Hansson as an example of “test induced design damage” during his Is TDD Dead? conversation series with Kent Beck and Martin Fowler. Putting that debate aside, though, here are some things this talk got me to understand more deeply or start thinking about: Differentiating between “framework” code that we don’t own, and “application” code that we do. It’s interesting to think about defining clear boundaries between these two types of code, and about decoupling…

Sandi Metz does Magic

This week, I’ll be posting links to some great conference talks that I’ve either attended in person or seen online. Sandi Metz gave a really great talk on proper testing, called The Magic Tricks of Testing at RailsConf 2013. I can’t wait to put some of her advice into action! Here are some memorable quotes from the talk: Integration tests are proof that the beast is alive! And: This is our job… To find the simplicity that lives at the heart of complexity.

Geographic Data, Rails, and Carmen

Instead of using the carmen-rails gem as an interface to carmen’s .yml geographic data, I am trying out a new way: putting carmen’s data directly into my db, and making Country, Subregion, and City into regular ActiveRecord::Base classes, making use of the composite_keys gem. Also, instead of storing the ISO codes in the database, I am storing the English place-names themselves. The rake task to move the data from carmen to the db is like this. And the models are like this. Pros: Easier to search database by English country name, because names, rather than codes, are stored in the…

Shoulda-Matchers and database-level not-null constraints

The shoulda-matchers gem makes it easy to test basic functionality of your app (mostly the model and controller layers it seems), without writing a whole lot of custom code. However, when using shoulda-matchers, if you have a database-level NOT NULL constraint on your model, then you may have to adjust how you write the tests in order for them to function properly. The following test of the uniqueness validation on unique_column won’t work if you have a NOT NULL constraint on the required_column at the database level: Instead, you first create a valid record (here this is done using a…

Using seeds.rb data for testing is a bad idea

My app’s database has some static tables for which the data will stay more or less unchanged throughout the life of the app. Two of the many examples are: List of world cities List of roles that users can be assigned to I was using seeds.rb to seed my production app, and I used the following code located in lib/tasks/test_seed.rake which seeded the database each time I ran This was a BAD IDEA, because: With more complex model specs, I have to clean out all the data in the db before running the test suite, otherwise I will get lots…