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

Testing binary downloads with Webrat

I’m using Webrat to keep some sanity when approaching maintenance of new application. Customers often come to me with legacy code, which somehow is not covered by tests.

In such case integration tests are way to go, since they provide most bang of Yours bucks – each written test could cover many parts of application.

I had to create test for testing download some data in CSV format (have You said binary? :) ). With default matchers from Webrat You won’t be able to write effective assertions – and that why I’m referring to such file as binary.


So how to do it? Here is a quick tip

Use Webrat’s response_body to get raw body returned by application. Like that:

click_link "Get me some CSV data"
ret = CSV.parse response_body
  "In third row and sixth column You should have 2 and there is #{ret[2][5]}"

How did I overcome TDD fear

I was using Rails for over two years, but I still was not truly converted to TDD. There was no special reason for it, I have tried few times with my own projects to take TDD approach. And I was quickly returning to plain, old code crunching.

Why? Maybe I haven’t approached TDD with enough determination to change my own habits – when I was starting new application, just write somehow seemed faster to me. Later I was creating some tests, just to check some most important (IMO) pieces of code. The thing which seemed being biggest obstacle was keeping set of fixtures to have data on which I can run tests. Problematic for me was having up to date fixtures – corresponding with current data model. I don’t know how about You, but when I approach new application I do usually have data model prepared only as very rough concept. This means that during development changes are often and notable. Editing every time set of fixtures… well each time it was reason I stopped TDD approach with my projects. I know. Maybe I should prepare data model in more detail before I start?

Recently I was preparing to bear with other type of project. For existing application I was supposed to create API providing some core features as RESTful interface. This was meant as wrap-up layer over existing code, not providing new features. But… Usually there is some but. Old code was not written by me, it was crappy and most of logic was in controllers instead of models.

I knew I need some test support (old code had no running tests – there were created at some point RSpec specifications, but models had changed since then, and RSpec was not updated). In other words – I wanted it or not, I was designated to take TDD approach.

Ride with TDD!

Ride with TDD! (c) Lachlan Hardy

But this time I got instant gratification – every test I wrote,it helped me understand what is going on in old code and let me be assured that I’m moving application logic from controllers to models without altering it. And fixtures – I have extracted them from real application data. With not changing data model two biggest obstacles were removed and… From now You can me count as another TDD zealot. Yes. I do see how much I have gained using TDD approach in this project, and could not imagine how I could work without it before. Well, we learn all the time.

Do You want to write less fixtures?

When writing functional test I would like sometimes to call methods in other controllers. Why, would You ask? Well… In most of cases it is related to fixtures or rather to my averse to maintain fixtures (I told You!). In case of API I was talking earlier, there were several models acting as helpers – they were representing some statuses of internal processes. Based on them final object was created. Sure I could write fixtures for them. But my point is – why to create those fixtures (and overhead to update them when model changes) when they can be prepared in test process?

What I’m talking about? Let’s assume we are preparing some reservations – to create Reservation based on search terms and set of available rates first we create Search (describes search terms), Result (set of matching rates with changes resulted from applied business logic – discounts, supercharges, etc). With those objects we can create final Reservation.

More – for those interim models I have wrote some tests, but treating whole process as a black box I could test it more efficient – I provide input data and I expect some final result – which is much more similar how this objects will be really used.

The only question was how to call those methods in other controllers inside of functional tests?

Methods for calling methods (put, get) available in functional test take action of current controller as argument, not path to run through Rails routing system. After short googling and looking into ActionController::TestCase I have noticed that current controller is defined by @controller variable (given method is just send to @controller). So, changing @controller is enough (storing it earlier for later usage):

class ExampleControllerTest < ActionController::TestCase
    def setup
      @controller = ExampleController.new
      @request    = ActionController::TestRequest.new
      @response   = ActionController::TestResponse.new
  should "call other controller before main test" do
   orig_controller = @controller
   @controller = SomeOtherController.new
   post :action_in_some_other_controller, {:argument => "value"}
   #get some data from @response
   #now we can return to original controller - just re-run setup
   @controller = orig_controller
   #let's tests begin!

As You can see I’m shoulda plugin fan :)

It has worked for me. What are pitfalls of this approach? I did not encounter any problems, but YMMV – I expect that re-using @response and @request can lead to some problems.

What else can be done to make fixtures more robust tool

I’m aware of Factory Girl, but from simple test I was conducting it is not huge time saver (however fixtures are in nicer format). I will take look at Machinist and try to write here more about FG and Machinist.

Any other ideas? Maybe there is some totally different way to accomplish my goal and I’m just not aware of it? I would appreciate Your opinions in comments.