2009-11-09 15 views
11

¿Puede alguien aclarar utilizando una historia de usuario SIMPLE la parte completa de para qué se usaría Cucumber y para qué se usaría RSpec? Compré el libro de RSpec el otro día y lo he estado revisando. El autor parece ser bastante vago a veces.TDD/BDD Rails Duplicación de pepino/RSpec

Lo que estoy pensando en si la historia de usuario es algo así como (disculpen la incorrección de sintaxis, esto es sólo para que pueda obtener el punto):

Cuando un usuario introduce un número de teléfono válido luego obtener un mensaje que dice "Número de teléfono inválido"

Si escribo todo el código de Cucumber para verificar esto y luego escribo el rspec, básicamente estoy duplicando mi prueba. ¿Hay un escenario para explicar cómo la prueba de pepino debe ser diferente de la prueba de rspec?

Siento que estarías duplicando pruebas en ambos niveles todo el tiempo.

Si no hay una respuesta definitiva sobre esto, voy a comenzar a pensar que la gente de Cucumber simplemente no quería pisar los dedos de los pies de RSpec.

Por favor ayuda. Siento que mi cabeza está a punto de explotar.

Gracias!

Respuesta

12

pepino se utiliza para explicar (hacer una descripción) de una pieza (historia) de la aplicación en lugar de las pruebas unitarias o pruebas de comportamiento (lo que es el foco de RSpec)

Por lo tanto, las pruebas en mi humilde opinión pepino (historias) no sustituya las pruebas de rspec.

Las pruebas de RSpec tienden a impulsar el desarrollo de los modelos y controladores, y las historias tienden a impulsar el desarrollo de las vistas.

Por su descripción parece como que está utilizando el pepino a prueba tanto las historias y el comportamiento

+0

Estoy totalmente de acuerdo, esta ha sido mi experiencia también. –

2

pepino se puede utilizar para ejecutar casi cualquier código, que es por eso que creo que está recibiendo confundido. Pero el pepino no proporciona otros tipos de instalaciones de prueba, como los métodos de burla y punteado, que hacen que las pruebas unitarias sean más específicas.

El objetivo de rspec es realmente tratar pequeños trozos de comportamiento y hacer que todo sea muy discreto. Si está familiarizado con las pruebas unitarias y los marcos para eso, esto debería tener más sentido.

La utilidad de pepino es poder traducir descripciones de alto nivel a un conjunto de acciones de nivel superior en el sistema.

5

Rspec y Cucumber son independientes y puede usar Cucumber y otro marco de prueba para sus pruebas (Test Unit, shoulda, etc.).

El punto es, ¿qué quieres probar con pepino? Porque de hecho podrías terminar la duplicación de pruebas y eso no sería realmente útil ¿no? :)

Hay diferentes filosofías con el pepino.

con Pepino que puede hacer:

DMA (directa significado modelo de acceso, sí se puede probar por completo su modelo igual que lo haría en rspec)

BrowZer simulada (acceso toda la pila MVC , sin Javascript)

navegador automatizado (uso webrat y selenio para acceder a sus puntos de vista, con javascript, más lento, BrowZer real)

Lo que me gusta hacer es utilizar pepino para comprobar lo que se devuelve al usuario. Esto generalmente tiene sentido cuando defino mis historias ya que no tengo realmente en mente el código que voy a escribir. Así que estoy probando el resultado final con Cucumber -> views (usando Browzer simulado o automatizado)

Luego uso rspec para probar cualquier código que escriba en los controladores y modelos.

Así, en su caso,

Cuando un usuario introduce un número de teléfono válido entonces consiguen un mensaje que dice "no válido número de teléfono"

me gustaría utilizar Webrat para comprobar que el usuario obtener el Número de teléfono no válido mensaje en la vista. Usaría Rspec para probar mi acción y modelo de controlador.

13

Podría ser útil para ver las capturas de pantalla en BDDCasts.com. Lo guiarán en la creación de historias y especificaciones para una aplicación. Realmente me ayudó. También posee el libro de rspec, pero todavía estaba confundido. Puede que incluso desees consultar su fuente en github.

Para mí dice así:

  • pepino para poner a prueba lo que el usuario verá. (Prueba de pila completa)

  • Rspec para probar todo lo demás. (Modelo, regulador)

6

Piense en Pepino como prueba toda su aplicación, de afuera hacia adentro, donde RSpec es la unidad de pruebas de módulos específicos. Empiezas especificando qué comportamientos quieres que tenga tu aplicación en Cucumber y luego ingresas a RSpec y describes las clases y módulos que hacen que funcione.

Me costó un poco conseguirlo, pero estoy descubriendo que Cucumber es muy bueno para describir en términos generales qué funciones desea que su aplicación haga y RSpec es realmente bueno para describir cómo debería hacerlo realmente.

Así que diría en sus historias de pepino qué tipo de característica desea y escriba pasos súper sencillos para proporcionar información y ver los resultados. Luego, desciende a RSpec y escribe especificaciones sobre cómo debería hacerlo realmente.

Digamos que su función es la capacidad de buscar nombres de usuario en un sitio web.Se podría escribir una función de pepino y la primera (y sólo la primera) escenario como este:

Feature: Search users 
    In order to find people with similar interests as myself 
    As a user 
    I want to search for people 

Scenario: Search for similar hobbies 
    Given there is a search page 
    And there is a list of hobbies 
    And one of the hobbies is "full contact ironing" 
    When I select "full contact ironing" 
    And press search 
    Then a list of users with the hobby "full contact ironing" are shown 

Ejecuta pepino, le indica los pasos que se está perdiendo, que copia los y crear los pasos simples para comprobar para esto, pero no escribas ningún código todavía.

Cuando termine con las definiciones de sus pasos, abra en RSpec y comience a escribir especificaciones sobre cómo desea que funcione. (Pepino, por supuesto, debe estar fallando)

describe "SearchController" do 

    it "should respond to searches" do 
    sc = SearchController.new 
    sc.should respond_to(:search) 
    end 

end 

Ejecuta RSpec y ver fracasar luego apagarse y escribir el código:

class SearchController 

    def search 
    end 

end 

Eso es todo. Ahora ejecuta tu prueba nuevamente. Debería pasar, así que comience a ser más específico y comience a describir cómo usará realmente la función de búsqueda. No quería profundizar demasiado en él. Solo quería darle la idea de que describa lo que quiere en Cucumber y luego describa cómo debería funcionar realmente en RSpec.

Por supuesto que puedes hacer todo en Cucumber o todo en RSpec, pero realmente he descubierto que Cucumber me ayuda a decir de manera muy simple lo que quiero, si trato de hacer eso en RSpec me atasco en los detalles. Si uso Cucumber primero para describir la función básica que quiero y por qué entonces puedo acceder a RSpec y decir cómo quiero que la función realmente funcione.

Habrá duplicaciones en sus pruebas a veces, que no son muy SECAS, pero si lo considera como un problema de nivel de detalle, puede que no le moleste demasiado. Estaba haciendo mucha duplicación de esfuerzos al principio hasta que me di cuenta de que debería decir en general lo que quiero en Cucumber y luego decir específicamente lo que quiero en RSpec.

Esto es solo la idea de un principiante de cómo usar las herramientas, pero parece que me funciona bien hasta ahora. Probablemente te he dado un ejemplo horrible, pero estoy tratando de transmitir el detalle general a detalles específicos que he encontrado útiles al usar las herramientas.

Cuestiones relacionadas