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.

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
    end
    
  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!
  end
end

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.