Evaluate

We want to afford the customer the ability to adapt to rapidly changing markets. Processes that restrict the customer’s ability to adjust the implementation strategy of their vision make it impossible to use change as a competitive advantage.

Iterate

Focus on current priorities, delivering value with a consistent cadence. As you iterate, allow for the customer to evaluate changing conditions in the marketplace.

Iterate. Evaluate. Repeat.

How Debuggers are Abused

Marking breakpoints and stepping through your code, evaluating each line and variable is a pretty typical practice. There are some developers who literally figuratively could not live without their debugger. I suspect this is most common in languages where IDEs are prevalent, but lets not forget about the modify-refresh-repeat paradigm in the PHP world.

Sometimes, when I come across some unexpected result or outcome, I will immediately add my debugger statement and start stepping through the code line-by-line echoing variables, assignments and conditionals to the terminal trying to track down my problem. Recently, I had a colleague scoff at the idea of not having ruby-debug for their rails project. The idea that we need this tool for day-to-day development is absurd.

Our One Step Program

When you’re testing the logic and/or output of your code with a debugger you’re making the mistake of not writing automated tests.

There are few problems that are solved via the manual and time-consuming process of a debugger that cannot be solved with an automated test. If you’re confused about the output of a calculation or method, write a quick unit test for that method. When the logic of your application doesn’t appear correct based on the input, maybe an integration test is in order to evaluate the flow of your program.

Not only do you get rid of the debugger baggage, you gain all of the other benefits that go along with testing.

BONUS: Excuse Resolution Table

If you’re getting ready to excuse your debugging behavior, check this list of resolutions first:

But excuse, I need a debugger…

Write more tests. Don’t have tests? Quit your job.

Scenario and Step

If you’re not familiar with multiline tables in cucumber, take a look at the wiki entry. We were specifying a list of attributes on one of our models that we wanted to have access to in our step. First, here is an example scenario outline.

1
2
3
4
5
6
7

Scenario: Finding a specific dog
  Given an existing microchipped dog named "George"
  When I search for a dog with the following attributes:
    | name   | microchipped |
    | George | true         |
  Then I find "1" dog
  And that dog should be named "George"

Our step was taking the multiline table attributes and using them in an ActiveRecord find, like this.

1
2
3
4
5

/^I search for a dog with the following attributes:$/ do |table|
  table.hashes.each do |attributes|
    @dog = Dog.find(:first, :conditions => attributes)
  end
end

In our example we are looking for two attributes a string called “name” and a boolean called “microchipped”. However, this find will always fail, even if your ‘Given an existing microchipped dog named “George”‘ step explicitly sets up the correct object in the beginning of the test.

The Fix

We found that if we changed our scenario to look like this, everything worked fine.

1
2
3
4
5
6
7

Scenario: Finding a specific dog
  Given an existing microchipped dog named "George"
  When I search for a dog with the following attributes:
    | name   | microchipped |
    | George | 1            |
  Then I find "1" dog
  And that dog should be named "George"

See the change? We changed “true” for microchipped to “1″. Typically when you’re working with rails you can pass true in the conditions of an ActiveRecord find and Rails will convert that to the correct SQL string for you. However, because cucumber passes each argument in the multiline table rows as strings, Rails never has the chance to covert that true for you.

In the first, failing, example you end up with something like this for your SQL:

SELECT * FROM dogs WHERE name = "George" AND microchipped = "true" LIMIT 1;

In the second, passing, example you end up with something like this:

SELECT * FROM dogs WHERE name = "George" AND microchipped = "1" LIMIT 1;