¿Cuándo debo probar las vistas por separado en el flujo de trabajo de Cucumber & RSpec?

Question

Después de un tiempo de hacer Cucumber & RSpec BDD, me di cuenta de que muchas de mis funciones de Cucumber son solo pruebas de nivel superior.

Cuando empiezo a escribir mi escenario y luego voy a RSpec, nunca escribo las especificaciones de vista, ya que podía simplemente copiar y pegar parte del escenario, lo que sería una duplicidad fea.

Tome este escenario, por ejemplo

Scenario: New user comes to the site 
    Given I am not signed in 
    When I go to the home page 
    Then I should see "Sign up free" 

Sé que esto no es la prueba directa de la vista, pero escribir especificaciones vista separada para comprobar si la misma cosa parece redundante para mí.

¿Me estoy acercando a Cucumber wrong? ¿Qué debo probar exactamente en las especificaciones de vista?

¿Debo escribir para cada vista única, por ejemplo, ensayos vistas para acciones tales como

def show 
    @project = current_user.projects.first 
end 

o debo probar vistas más complejas?

Answer 1

Es una filosofía ampliamente aceptada (y en mi opinión, incorrecta) de Cucumber que las opiniones deben nunca probarse dentro de RSpec. El argumento es que dado que el comportamiento de la vista se puede describir en Cucumber, RSpec debe ajustarse a lo que mejor se conoce: Modelos y Controladores.

Argumento que el aspecto "legible para los humanos" de Cucumber hace que algunos aspectos de la especificación de la vista sean importantes. Por ejemplo, encuentro que las especificaciones de vista funcionan muy bien cuando se trabaja en paralelo con un desarrollador front-end. Si un desarrollador de JavaScript sabe que va a querer enganchar en un selector en su página, es importante que su vista proporcione ese selector.

Por ejemplo:

describe 'gremlins/show.html.haml' do 
    context 'given it is after midnight' do 
    it 'has a #gremlin_warning selector' do 
     Time.stub!(:now).and_return(Time.parse '2010-12-16 00:01:00') 
     rendered.should have_selector '#gremlin_warning' 
    end 
    end 

    context 'it is before midnight' do 
    it 'does not have a #gremlin_warning selector' do 
     Time.stub!(:now).and_return(Time.parse '2010-12-16 23:59:00') 
     rendered.should_not have_selector '#gremlin_warning' 
    end 
    end 
end 

Tenga en cuenta que las especificaciones no describen el contenido, que es intencionalmente breve, y no describen comportamientos de interacción. Debido a que la vista es la parte de su aplicación que cambiará más, las especificaciones de vista deben usarse con moderación.

tl; dr: Ver especificaciones son para comunicar un contrato para otros desarrolladores y debe utilizarse con moderación (pero no obstante debe ser utilizado).

Answer 2

Personalmente, nunca uso las especificaciones de vista cuando uso Cucumber. Para mí, las pruebas de aceptación tienen mucho más sentido, y mis puntos de vista complejos generalmente se centran en Javascript y no se pueden probar usando las especificaciones de vista.

Answer 3

No utilice las especificaciones de vista para nada, nunca. Las historias de pepino, o incluso las pruebas de integración de RSpec, lo hacen mejor. Los ejemplos que bobocopy da son buenos para el caso que postula, pero deberían incluirse en las historias/pruebas de integración de Cucumber, que no se dejan solas.