Is shoulda destroying my backtraces?

Question

I have a test more or less like this:

class FormDefinitionTest < ActiveSupport::TestCase
  context "a form_definition" do
    setup do
      @definition = SeedData.form_definition
      # ...

I've purposely added a

raise "blah"

somewhere down the road and I get this error:

RuntimeError: blah
test/unit/form_definition_test.rb:79:in `__bind_1290079321_362430'

when I should be getting something along:

/Users/pupeno/projectx/db/seed/sheet_definitions.rb:17:in `sheet_definition': blah (RuntimeError)
    from /Users/pupeno/projectx/db/seed/form_definitions.rb:4:in `form_definition'
    from /Users/pupeno/projectx/test/unit/form_definition_test.rb:79

Any ideas what is sanitizing/destroying my backtraces? My suspicious is shoulda because the when the exception happens inside a setup or should is whet it happens.

This is a Rails 3 project, in case that's important.

Alixaliza

why do this raise if you want raise some exception ? If it's a test, it's not the format to do. – Breezeway

@Breezeway I'm doing that raise just to see how it looks like. What's really happen is that I'm getting an exception from somewhere, another exception, but I can't find where since something is hiding most of the backtrace. – Alixaliza

All stacktrace you report are from your "raise blah". So I don't understand your really problem – Breezeway

@shingara: my problem is that the stack trace when the error occurs inside a method called from setup or should, doesn't contain all the frames up to the raise itself. form_definition_test.rb:79 doesn't raise "blah", it's raised by a method called by another method call by it, as you can see in the second stack trace. – Alixaliza

@J. Pablo Fernandez: If you're adding a raise "blah" in order to post a minimal (reproducible) example, we would appreciate it if you could post a minimal example that we can run ourselves (without having to add any code ourselves) to reproduce the problem. – Coactive

I'm having this problem too. Did you ever figure it out? – Timehonored

The problem he is trying to report is that shoulda seems to somehow swallow the exceptions raised along the test, thus hidding their stack trace. I am having the same problem. – Heterolecithal

maybe the backtrace silencers are messing with you. Read the comment in config/initializers/backtrace_silencers.rb. I usually remove all the cleaners. I can live with long backtraces. – Deimos

Answer 1

That is because the shoulda method #context is generating code for you. for each #should block it generates a completely separate test for you so e.g.

class FormDefinitionTest < ActiveSupport::TestCase
  context "a form_definition" do
    setup do
      @definition = SeedData.form_definition
    end

    should "verify some condition" do
      assert something
    end

    should "verify some other condition" do
      assert something_else
    end
  end
end

Then #should will generate two completely independent tests (for the two invocations of #should), one that executes

      @definition = SeedData.form_definition
      assert something

and another one that executes

      @definition = SeedData.form_definition
      assert something_else

It is worth noting that it does not generate one single test executing all three steps in a sequence.

These generated blocks of codes have method names like _bind_ something and the generated test have name that is a concatenation of all names of the contexts traversed to the should block plus the string provided by the should block (prefixed with "should "). There is another example in the documentation for shoulda-context.

Arica

Answer 2

I think this will give you the backtrace that you want. I haven't tested it, but it should work:

def exclude_backtrace_from_location(location)
  begin
    yeild
  rescue => e
    puts "Error of type #{e.class} with message: #{e.to_s}.\nBacktrace:"
    back=e.backtrace
    back.delete_if {|b| b~=/\A#{location}.+/}
    puts back
  end
end

exclude_backrace_from_location("test/unit") do
  #some shoulda code that raises...
end

Teutonic

Answer 3

Have you checked config/initializers/backtrace_silencers.rb? That is the entry point to customize that behavior. With Rails.backtrace_cleaner.remove_silencers! you can cleanup the silencers stack.

More informations about ActiveSupport::BacktraceCleaner can be found here.

Rickyrico