Extracting fixtures

I’m still using fixtures. Shame, I know.

Why I do use them instead of Factory Girl or other solution like that? Well, fixtures can be much more closer to real data than mocks from Factory. How come, You ask? Fixtures are imaginary data exactly like mocks from other sources!

My answer is: that depends how You create fixtures. If You create them by hand, indeed they are disconnected from real world (like all mocks).

What is Your real data/mocks ratio?

What is Your real data/mocks ratio? CC by hsing

But I prefer to extract fixtures from real (production) database. That way I can easily pick entries created by users which are edge cases. The only trouble is with creating fixtures. For some time I’m using modified extract_fixtures rake task. I have added some conditions to extracting process – SQL condition to select only particular records and adjusted syntax to recent rake.

This is useful especially when You are about to take over application code which has no tests. Extracting real data is quick way to start write integration tests (in such case they have are most efficient – time invested and application code coverage).

How to extract fixtures without pain?

Continue reading

Shoulda You abandon Test::Unit?

I was not very keen on RSpec. Well to be honest I had some problems with writing tests at all. Fortunately old and bad times are gone. I mean writing test is now much more natural and has become second nature. That way I don’t need to force myself to write them. You know, attacking new ideas is much more sexier than boring (most of time) tests ;)

As freelancer I do often jump into some established project, with long history and different tools used. This has advantage I can watch other developers how theirs code looks, and learn from it how things can be done (there are always exceptions).

In one of such projects I’ve found Shoulda plugin. This plugin adds to Test::Unit bunch of nifty helpers, making live much easier.

First, stop writing those damn underscores and make tests much more readable:

context "Facebook app" do
    context "when removed " do
      setup do
         #some init code
      end
      
      should "accept only HTTP post" do
          #request and assertions
      end
      
      should "clear FB bindings" do
         #request and assertions
      end
    end
end

context allow to group tests and provide some common setup phase. Naming tests is much more easier and allow DRY, making test titles much more compact. However when running tests it will output names of tests (when some errors/failures) perpending them with all context names.

"Facebook app when removed should accept only HTTP post"
"Facebook app when removed should clear FB bindings"

More readable? You bet! But that is not all! Helpers to make even more less typing, this time with assertions. Just check docs for this plugin (note there is also non-rails version, Shoulda gem, which provides cut-down features, but is not coupled with Rails, so can be used in other projects using Test::Unit).

For me, RSpec is still not test framework of choice. Maybe the other day I will drink RSpec’s Kool-Aid, but for now I prefer Test::Unit + Shoulda plugin.

If there are some RSpec zealots, what is reason for You to choose it over Test::Unit?