Future on Rails

Using Rails

Archive for May 2009

The Widespread Abuse of Fixtures

leave a comment »

I thought, everyone on this planet already knew about the purpose of fixtures in Rails…unfortunately I see ย the abuse of fixtures in many projects out there.

Fixtures are used by developers for many purposes: unit testing, integration testing or populating the DB with default data. But from all these usage scenarios, fixtures are really only good for integration testing! Don’t use fixtures for unit testing! Don’t use fixtures for populating the DB with default data!

Why not to use fixtures for unit testing?

Fixtures for unit testing is a bad idea. The main reason is that your unit tests become hard to read, because you need two code artefacts to understand them. You also introduce a dependency between test and fixtures (and between this test and other tests using the same fixture data!). It is recommended by most developers, to build unit test objects directly in the test class. This makes every test precondition explicit in the code. It is also easy, because you usually only need an object of one class (without associations).

Why not use fixtures for populating the DB?

It is also very common, to use fixtures for loading default or sample data into the database. But since fixtures are also used for (automated) testing, you might want to separate those two concerns. My recommendation is to use fixtures exclusively for automated integration testing and to use a rake task to populate the DB with default data or test data for manual testing. By using gems like Populator and Faker, you can also quickly create sensible, randomized test data, so that your human testers can do their job. See the great Railscast on “Populating a Database”.

Written by Matthias Orgler

May 11, 2009 at 1:03 pm

Posted in Uncategorized


leave a comment »

Subversion is a fantastic versioning system (although there’s all the hype about git (to which I am actually switching now)). In the past I stumbled across two problems I want to share with you (including a solution ๐Ÿ˜‰ ):

The first thing is that my IDE (Eclipse/Aptana) doesn’t support the latest SVN version. I use Subclipse in the latest version, but I sometimes receive errors that can only be overcome by deleting the whole project and checking it out again. Furthermore Subclipse is not compatible with the latest console version of SVN. Why do I use the console version? Because it is easier to include versioning tasks in Ant or Capistrano or to simply type stuff in the console (as it is common when developing RoR). So finally I disconnected all my projects in Aptana and went ahead to only using the console version of SVN. My experience: the console version is as easy to use as Subclipse, once you’ve learnt a few commands. For everyone wanting to work fast and seeking to avoid trouble, I would recommend to use SVN directly via console.

Another problem I had was to remove directories from SVN via the command line tool. Simply deleting the directory and then trying to check in didn’t work, because SVN was missing the .svn data for that directory. I had to google a little bit to find the simple solution: “svn rm <dir>” will remove a directory from SVN, even if it’s already deleted locally.

Hope this helps some of you to avoid some of the trouble I had ๐Ÿ˜‰

P.S.: Oh, a bonus solution I had to google for in the beginning: If you want to add several new files to your existing repository (e.g. those created by a generator), a simple “svn add .” won’t work. What you want to do is use “svn add . –force” to avoid the warnings SVN gives you for all the already existing files :).

Written by Matthias Orgler

May 5, 2009 at 3:34 pm

Posted in scm

Tagged with , ,