¿Es Cucumber simplemente un contenedor de rspec para ayudar a organizar las pruebas en las características?

Question

Solo quiero asegurarme de que entiendo las cosas.

Según lo que he deducido hasta ahora, Cucumber es simplemente una 'envoltura' o una buena forma de organizar tus pruebas clasificando las cosas en características y pasos, donde las pruebas unitarias reales están en la fase de pasos.

Permite organizar sus pruebas para ver cómo funcionan las cosas.

¿Es correcto?

Answer 1

Tipo de.

Es es una forma de organizar las pruebas, pero es más que eso. Se comporta como se suponía que debían las pruebas de integración originales de Rails, pero es mucho más fácil de usar. La gran victoria aquí es que su sesión se mantiene de forma transparente en todo el Scenario.

Otra cosa que está pasando con Cucumber es que se supone que (usted debe estar) probando desde el punto de vista de un navegador o cliente utilizando su código. Si lo desea, puede usar los pasos para construir objetos y configurar el estado, pero generalmente desea que sus pasos sean los necesarios para lograr ese estado en primer lugar.

Por ejemplo, usted podría hacer esto:

Given /I have a user account/ do 
    @user = Factory.create(:user) 
    # ... more user set up 
end 

Pero probablemente debería hacer algo como esto en su lugar:

Given /I have a user account/ do 
    visit new_user_url 
    fill_in "user_login", :with => "some name" 
    fill_in "user_password", :with => "foo" 
    # ... whatever else your sign up page needs 
end 

Y, por supuesto, se puede pasar en los argumentos a cualquiera de esos pasos para darle a su código de llamada un control más detallado sobre el comportamiento del paso.

Lo que generalmente he estado haciendo con mis pruebas es el siguiente.

1. Uso shoulda, pero rspec también está bien.
2. Escribo mis pruebas de autenticación negativa (es decir, se espera el acceso denegado) como pruebas funcionales de Rails.
3. Escribo mis pruebas de autenticación positiva (es decir, usuarios que hacen lo que se supone que deben hacer) como funciones de Cucumber.

Y, por supuesto, todavía escribir pruebas unitarias rieles para mis modelos, bibliotecas, ayudantes, etc.

Answer 2

I como el pepino, ya que describe lo que el comportamiento es sin describir cómo es implementado. El pepino básicamente desacopla la especificación (que también es una prueba de aceptación/regresión ejecutable) de la implementación. Las definiciones de paso son el adaptador entre la especificación y el sistema bajo prueba, que permite el desacoplamiento.

También puede argumentar que Cucumber le da una especificación más humana que RSpec u otras sintaxis basadas en Ruby, que pueden ser entendidas (incluso escritas) por un cliente no programador.

Answer 3

Yo diría que usted entiende es incorrecto.

La prueba de la unidad y los pasos del pepino son cosas completamente diferentes y no relacionadas en gran medida.

Las pruebas de pepino son combinaciones pruebas de integración/aceptación del usuario y como tales se supone que son independientes de la implementación real en el código. Entonces, en teoría, podría reescribir completamente su aplicación en un idioma diferente y las pruebas de pepino y los posibles pasos aún deberían ser útiles, suponiendo que no haya cambiado el comportamiento de las aplicaciones. Las pruebas unitarias, por otro lado, están íntimamente relacionadas con el código, probando cosas como valores de retorno de llamadas a métodos específicos, casos límite relacionados con estructuras de datos, etc. Cambie un método y debe cambiar la prueba unitaria.

Hay algunos buenos screencasts que hablan sobre el uso de Cucumber y RSpec para construir/probar su aplicación desde afuera. Aquí están algunos que deben ayudarle a empezar a mejorar su comprensión de cómo las pruebas de integración y pruebas unitarias pueden encajar:

http://blog.josephwilk.net/ruby/outside-in-development-with-cucumber-and-rspec.html

http://rubyconf2008.confreaks.com/rspec-and-cucumber.html

http://confreaks.net/videos/72-mwrc2009-bdd-with-cucumber

mi uso personal del pepino es una Un poco herético, ya que a menudo uso solo pepino en proyectos más pequeños, ya que reemplaza la monotonía de ejecutar y volver a ejecutar scripts que no son lo suficientemente importantes como para hacer un desarrollo basado en pruebas de unidades completas. Sin embargo, definitivamente este no es el consenso de la comunidad (al menos en público) sobre cómo hacer las cosas.

Answer 4

El pepino no es un envoltorio alrededor de RSpec. RSpec es una herramienta que se usa para controlar su código a nivel de unidad (una clase a la vez), mientras que pepino es una herramienta para definir características de su sistema que a su vez son automáticas.

Las especificaciones de RSpec normalmente se escriben una por una a medida que evoluciona la base de código. Especificamos el siguiente pequeño comportamiento de la clase que estamos escribiendo actualmente.

Contraste eso con Cucumber donde escribimos un conjunto de Escenarios que no son más que un ejemplo de cómo el sistema será utilizado por un usuario final. Normalmente, la mayoría de los escenarios se escriben antes del comienzo del desarrollo y sirven para definir qué funcionalidad debe contener la característica. En un entorno Ágil, una característica se considera funcionalmente completa cuando pasan todos los Escenarios.

En tiendas más pequeñas, los desarrolladores escriben tanto las características/escenarios de Cucumber como las especificaciones de RSpec. En las tiendas más grandes, estas actividades se dividen entre los desarrolladores que escriben las especificaciones, mientras que los propietarios y probadores del producto escriben y automatizan los escenarios.