2011-02-16 16 views
5

Tengo tres versiones de un backend que estoy probando. Me gustaría ejecutar especificaciones de características similares en comparación con las tres versiones.Pepino: cómo organizar un conjunto de prueba complejo

Al principio, pensé que acababa de organizar todo en una estructura de directorios, tales como:

features/ 
    v1/ 
    something.feature 
    step_definitions/ 
     something_steps.rb 
    v2/ 
    something.feature 
    step_definitions/ 
     something_steps.rb 
    v3/ 
    something.feature 
    step_definitions/ 
     something_steps.rb 

Sin embargo, pepino parece acople todo, lo que significa que termino con las definiciones ambiguas paso.

entonces pensé en la siguiente estructura:

features/ 
    v1/ 
    something.feature 
    v2/ 
    something.feature 
    v3/ 
    something.feature 
    step_definitions/ 
    something_steps.rb 

Me defino una variable en el archivo de función en algún lugar, lo que indica cuál es la versión que uno es para, y me gustaría tener un montón de "si" dentro del archivo de pasos, para elegir rutas de código dependiendo de esa variable de versión. Sin embargo, no he encontrado una forma obvia de definir esa variable en el archivo de características.

¿Hay alguna manera en que pueda organizar las cosas, o tendré que crear varias raíces "características", una por versión, lo que sería una solución horrible dado que implicaría múltiples invocaciones de pepino?

v1/ 
    features/ 
    something.feature 
    step_definitions/ 
     something_steps.rb 
v2/ 
    features/ 
    something.feature 
    step_definitions/ 
     something_steps.rb 
v3/ 
    features/ 
    something.feature 
    step_definitions/ 
     something_steps.rb 
+0

Enchufe desvergonzado - De hecho, escribí una joya para ayudar con esta situación exacta: https://github.com/jmerrifield/cuke_iterations –

Respuesta

6

¿Por qué sería múltiple invocaciones de pepino ser una mala cosa? Personalmente, así es como lo haría, y ejecutar las tres características de un Rakefile, así que no tuve que hacer una después de la otra.

Además, si los conflictos son tan grandes que está reescribiendo la definición del paso completo para cada versión, tal vez debería reconsiderar cómo los está redactando. ¿Deberías describirlo realmente haciendo lo mismo si el código es tan diferente?

Si los cambios son más pequeños, sugiero mirar tags y hooks para lograr lo que desea.

Por lo que su función podría tener este aspecto:

@v1 
Feature: some feature 
    In order to test different versions 
    As a cucumber user 
    I want to be able to change step definitions based on what version feature is running 

    Scenario: some scenario 
    Given some thing 
    When I pass some method 
    Then I should get something 

Y su definición de paso podría tener este aspecto:

Before('@v1') do 
    Thing = V1Thing 
    VERSION = 1 
end 

Given /^some thing&/ do 
    @thing = Thing.new 
end 

When /^I pass some method$/ do 
    @thing.some_action! 
end 

Then /^I should get something$/ 
    thing = "something" if VERSION == 1 
    thing = "something else" if VERSION == 2 
    @thing.prop.should == thing 
end 

Puede utilizar este método, incluso si las definiciones de paso son muy diferentes, pero Creo que será más difícil de manejar.

+0

El problema con las múltiples invocaciones es realmente la capacidad de obtener todos los resultados compilados en un buen conjunto de resultados , para propósitos de compilaciones continuas, etc. El enfoque que mencionaste es el que terminé tomando, ¡gracias! –

Cuestiones relacionadas