variables de instancia del controlador de pruebas con el estante :: Prueba y Sinatra

Question

Tengo una aplicación que sirve Sinatra páginas como de sólo lectura o modificable en función de si el usuario está conectado.

El controlador establece una variable @can_edit, que es utilizado por las vistas para ocultar/mostrar enlaces de edición. ¿Cómo puedo probar el valor @can_edit en mis pruebas? No tengo idea de cómo llegar a la instancia actual del controlador en Rack :: Test.

utilizo class_eval al stub del método logged_in? en el controlador, pero estoy teniendo que recurrir a la comprobación last_response.body para mis editar enlaces para ver si @can_edit se ha establecido o no.

¿Cómo puedo probar el valor de @can_edit directamente?

Answer 1

Lamentablemente, no creo que esto sea posible sin modificar Rack :: Test. Cuando se hace una solicitud durante las pruebas de aplicaciones, Cambio :: prueba consiste en lo siguiente:

1. añade la solicitud a una lista de peticiones recientes
2. crea una nueva instancia de la aplicación e invoca su método call
3. agrega la respuesta de su aplicación a una lista de respuestas recientes

es fácil acceder al last_request y last_response, pero por desgracia no se guardará información sobre el estado de su solicitud, mientras que es Runni ng.

Si está interesado en hackear un parche Rack :: Test para hacer esto, comience por mirar rack-test/lib/rack/mock_session.rb en la línea 30. Aquí es donde Rack :: Test ejecuta su aplicación y recibe los valores de retorno de la aplicación Rack estándar (estado, encabezados, cuerpo). Supongo que tendrá que modificar su aplicación también, para recopilar y hacer accesibles todas sus variables de instancia.

En cualquier caso, es mejor probar los resultados, no los detalles de implementación. Si desea asegurarse de que un enlace de edición no es visible, la prueba de la presencia del enlace de edición de DOM id:

assert last_response.body.match(/<a href="..." id="...">/) 

Answer 2

Es posible con un pequeño truco. Las instancias de la aplicación Sinatra no están disponibles porque se crean cuando se llama a la llamada Sinatra :: Base #. como Alex explicó. Este truco prepara una instancia adelante y deja que la próxima llamada la atrape.

require 'something/to/be/required' 

class Sinatra::Base 
    @@prepared = nil 

    def self.onion_core 
    onion = prototype 
    loop do 
     onion = onion.instance_variable_get('@app') 
     return onion if onion.class == self || onion.nil? 
    end 
    end 

    def self.prepare_instance 
    @@prepared = onion_core 
    end 

    # Override 
    def call(env) 
    d = @@prepared || dup 
    @@prepared = nil 
    d.call!(env) 
    end 
end 

describe 'An Sinatra app' do 
    include Rack::Test::Methods 

    def app 
    Sinatra::Application 
    end 

    it 'prepares an app instance on ahead' do 
    app_instance = app.prepare_instance  
    get '/foo' 
    app_instance.instance_variable_get('@can_edit').should be_true 
    end 
end 

me di cuenta de esta técnica para mock the instance that runs the current test en el primer lugar.

Answer 3

Heres una alternativa viable desagradable pero

# app.rb - sets an instance variable for all routes 
before do 
    @foo = 'bar' 
end 

# spec.rb 
it 'sets an instance variable via before filter' do 
    my_app = MySinatraApplication 
    expected_value = nil 
    # define a fake route 
    my_app.get '/before-filter-test' do 
    # as previously stated, Sinatra app instance isn't avaiable until #call is performed 
    expected_value = @foo 
    end 
    my_app.new.call({ 
    'REQUEST_METHOD' => 'GET', 
    'PATH_INFO' => '/before-filter-test', 
    'rack.input' => StringIO.new 
    }) 
    expect(expected_value).to eq('bar') 
end 

Esto le permite probar contra un Sinatra antes de variables de filtro y de instancia o de acceso creado para la aplicación de base.