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 =
      @request    =
      @response   =
  should "call other controller before main test" do
   orig_controller = @controller
   @controller =
   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.

Simple search in Rails applications

Almost every application does need search feature. Even if not direct feature You need some efficient way to narrow data selection. And I do like to have clean and compact code :) so I have spent some time to create my own search schema which I’d like to share with You.

First – what I’m talking about? Let’s assume You need to create some kind of report and has to provide several options to narrow down scope of entries. Since Active Record requires You to create part of SQL query in :conditions it is easy to create some not nice looking code with string joining, wondering if You should add AND operator and so on.

In most cases You don’t need full blown search capabilities (like with Ferret) and You want to keep Your dependencies list as short as possible.

How to search?

Right tools when You need to see some details

Right tools when You need to see some details (c) Wrote

I came up with following code:

conditions = ["1=1"]
cond_data = []
includes = [:association_used_for_display]

unless params[:condition_1].blank?
  conditions << "field_1 = ?"
  cond_data << params[:condition_1]

unless params[:condition_2].blank?
  conditions << "other_table.field_2 = ?"
  cond_data << params[:condition_2]
  includes << :some_association #for other_table

unless params[:condition_3].blank?
  conditions << "one_more_table.field_3 like ?"
  cond_data << "#{params[:field_3]}%"
  includes << :one_more_association #to get one_more_table

@results = Model.find(
  :conditions => [ conditions.join(" and "), *cond_data ],
  :include => includes)

The idea is to keep array conditions with entries to create :conditions option and cond_data array to keep arguments to substitute all question marks.

With includes we can add associations we need to load when criteria need it. We can preset some associations to force load some data always needed for view creation (association_used_for_display in this example).

Using this schema allows easilly add new criteria – it just another unless statement.

So what do You think about it?

I’m curious what do You think about this approach – or You do have some own solutions? I’m waiting for Your comments!

Rake and arguments for tasks

Rake is beautiful tool, helping automate many tasks using Ruby. When You want to pass some arguments You can add VAR=value on command line and then in task use ENV['VAR'] to access passed value. But it is not what You alway want. Sometimes You want more compact and clean way to pass arguments.

Starting with Rake 0.8.0 You can create tasks with arguments:

task :name, [:first_name, :last_name] do |t, args|
     args.with_defaults(:first_name => "John", :last_name => "Dough")
     puts "First name is #{args.first_name}"
     puts "Last  name is #{args.last_name}"

Now You can pass some arguments:

C:\>rake name
(in C:/)
First name is John
Last  name is Dough

C:\>rake name[Jim,Weirich]
(in C:/)
First name is Jim
Last  name is Weirich

Cool. I guess I don’t need to explain how arguments and setting default values does work?

However I have noticed some error. First documentation skip needed key in example when task have some dependency on other task (:needs) and argument names should be provided not as an array (for task without dependencies both array and list form are working). Here is example of task with two arguments and one dependency, which does work (I’m using Rake 0.8.3):

task :name, :first_name, :last_name, :needs => [:other] do |t, args|
     args.with_defaults(:first_name => "John", :last_name => "Dough")
     puts "First name is #{args.first_name}"
     puts "Last  name is #{args.last_name}"

task :other  do

What You can do with args?

Here it is modified task from Chad Fowlers Rails Recipes to dump data from database to fixtures. Handy to populate fixtures with some data entered with WWW interface:

desc 'Create YAML test fixtures from data in an existing database.
Defaults to development database. Set RAILS_ENV to override. Use args
table and limit to dump one table and limit number of records'
task :extract_fixtures, :table, :limit, :needs => :environment do |t, args|
  args.with_defaults(:table => nil, :limit => nil)
  limit = args.limit.nil? ? "" : "LIMIT #{args.limit}"
  sql = "SELECT * FROM %s #{limit}"
  skip_tables = ["schema_info" ]
  if args.table.nil?
     tables = ActiveRecord::Base.connection.tables - skip_tables
    tables = [ "#{args.table}"]

  tables.each do |table_name|
    i = "000""#{RAILS_ROOT}/test/fixtures/#{table_name}.yml" , 'w' ) do |file|
      data = ActiveRecord::Base.connection.select_all(sql % table_name)
      file.write data.inject({}) { |hash, record|
        hash["#{table_name}_#{i.succ!}" ] = record

You can dump all fixtures or only single table and limit it to first X entries. I find it useful recipe, I hope it can be used by someone else, too.

NetBeans, Subversion, SSH and Windows

I have wasted a lot time to fight simple issue. I need to use Subversion on svn+ssh protocol with NetBeans. I was using NB Subversion FAQ, and could not get it up and running.

On Windows there is de facato standard of SSH client – it is PuTTY. I was using plink to provide access to remote server. Now – if You have IP address set for default connection in PuTTY, then whole fix described in NB SVN FAQ does not work!!. Just make sure that You have empty Host Name (or IP Address) field in PuTTY for session Default Session

Django, anyone?

I do write this blog in English (duh, at least I try :) ) but according to Google Analytics readers from Poland are quite numerous so…

Friend of mine (Marcin Kaszy?ski) in October will run workshops “Creating applications with Django“. If You want to learn about Django framework You have good opportunity to gain some knowledge straight from someone very experienced with this framework.

Workshops will be held in Warsaw (in Polish), in small group – don’t miss this event.