At Highgroove we really like testing and are constantly looking for ways to improve our testing process, how quickly our tests run, and how exactly we execute our tests. How often during your Test Driven Development (TDD) cycle do your tests fail “mysteriously”? You’ve written your tests, written your code, and most of them pass but one or two stubbornly fail even though you are fairly certain they should pass given the testing setup you’ve provided? At Highgroove we bias towards action so we are likely to launch a debugger session or a pry session to get to the bottom of this. Another approach, which won’t break your existing TDD workflow, is to use your test-suite in place of a more traditional debugger. After the jump we’ll talk about how we’ve been using this strategy to dig into code quickly and easily.

Often the above situation comes about during testing of complicated objects where a given assertion relies on several elements of state being correct. For this discussion the examples will be in RSpec 2 though any test-suite should be able to perform the same assertions with a simple change of syntax.

Assume you start with a simple example such as

If the #compound? example above fails then clearly one of the three properties being checked is not in the expected state. You could do something like launch the debugger, launch the rails console, or bind a pry session and dig into the objects. All of these would work so lets examine the rails console version:

If we had used pry, ruby-debug, or even awesome_print and examined the object manually, we would have almost certainly done exactly those queries of our object to determine state. Since we doing proper TDD we probably have both our tests and our code open simultaneously, and some way of quickly running our test-suite such as vim-vroom or guard-rspec or some other custom set of bindings or tool, so why then do we context switch into yet another tool to debug object state when RSpec is essentially a DSL for doing just that?!?

Thus we can change our spec to do our custom querying as follows:

which produces:

In all likelihood we want to change our object creation step in FactoryGirl for this test of the predicate. We can make that deterination and change in one place without context switching, and decide to leave or remove those predicate checks before moving onto the next story or riding bikes. What do you do to debug or otherwise investigate the state of your objects without breaking your flow?