¿Debería destruir mis antecedentes?

Question

tengo una prueba más o menos así:

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

He añadido deliberadamente un

raise "blah" 

algún lugar del camino y me sale este error:

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

cuando Debería obtener algo junto:

/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 

¿Alguna idea de lo que está desinfectando/destruyendo mis trazas? Mi sospecha es debido a que cuando la excepción ocurre dentro de una configuración o si es que sucede.

Este es un proyecto de Rails 3, en caso de que sea importante.

Answer 1

Creo que esto le dará la traza inversa que desee. Yo no lo he probado, pero debería funcionar:

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 

Answer 2

¿Ha comprobado config/initializers/backtrace_silencers.rb? Ese es el punto de entrada para personalizar ese comportamiento. Con Rails.backtrace_cleaner.remove_silencers! puede limpiar la pila de silenciadores.

Más información sobre ActiveSupport::BacktraceCleaner se puede encontrar here.

Answer 3

Esto se debe a que el método H0DA #context genera código para usted. para cada bloque #should genera una prueba completamente independiente para usted, por ejemplo,

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 

Entonces #should generará dos pruebas totalmente independientes (por las dos invocaciones de #should), que ejecuta

 @definition = SeedData.form_definition 
     assert something 

y otro que ejecuta

 @definition = SeedData.form_definition 
     assert something_else 

Vale la pena señalar que lo hace no genera una sola prueba ejecutando los tres pasos en una secuencia.

Estos bloques generados de códigos tienen nombres de métodos como _bind_ algo y la prueba generada tiene un nombre que es una concatenación de todos los nombres de los contextos atravesados ​​al bloque should más la cadena proporcionada por el debería bloquear (con el prefijo "debería") Hay another example in the documentation for shoulda-context.