Mi 'ah-ha!' Llegaron momentos sobre las pruebas en Ruby and Rails cuando realmente me senté y leí los recursos definitivos sobre el tema, los libros Rspec y Cucumber . Compartí tu desdén inicial de Pepino, pero luego me di cuenta de que estaba mirando la imagen desde un ángulo bastante equivocado.
Básicamente, Cucumber se trata de BDD (desarrollo impulsado por el comportamiento): usted usa Cucumber para planificar sus características, en lo que va a trabajar a continuación. Hmm, luego quieres que los usuarios puedan promocionar publicaciones en un foro o algo así (para robar un ejemplo;)) Entonces escribes algo simple.
Given I am logged in
And I can see the post "BDD is awesome"
When I vote the post up
Then the post should have one more vote
And the page should show a message thanking me for my vote.
Tenga en cuenta que no hay referencias a nada de código relacionado allí más o menos. Eso viene en tus pasos. Cuando refactorice su código, es posible que tenga que cambiar sus definiciones de pasos, pero el comportamiento (su característica) nunca tendrá que cambiar.
Ahora, cada vez que ejecute su función Cucumber, se le guiará a través de cómo probar la función usando TDD (desarrollo impulsado por pruebas). Esto se hace en un nivel inferior usando RSpec.
Primera ejecución: la definición de mi primer paso no está definida. Copie el bloque para definirlo en say user_steps.rb o incluso session_steps.rb porque se relaciona con los usuarios y sus sesiones. Ahora, ¿cómo define que un usuario ha iniciado sesión? Puede llevarlos a través del proceso de inicio de sesión.
Given /^I am logged in$/ do
visit login_path
fill_in :name, :with => 'Joe'
fill_in :password, :with => 'Password'
click_button 'submit'
end
Debería estar todo feliz. Segundo paso.
Given /^I can see the post "(.+)"$/ do |name|
visit post_path(Post.find_by_name(name))
end
De nuevo bastante fácil. Tenga en cuenta que si rehacemos totalmente nuestro proceso de inicio de sesión, o cómo se definen y muestran nuestras publicaciones, no tenemos que cambiar el comportamiento. Tercer paso.
When /^I vote the post up$/ do
pending
end
Aquí es donde está comenzando a hablar sobre la nueva funcionalidad, pero aún no sabe cómo va a funcionar. ¿Cómo se vota una publicación? Puede hacer clic en una imagen de un +1 o algo, que hace una publicación ajax en un controlador, que devuelve JSON, o algo así. Así que ahora puedes pasar a las pruebas Rspec puras.
- Pruebe su vista para asegurarse de que se muestre la imagen +1,
- Pruebe su controlador para que se comporte correctamente cuando reciba una solicitud ajax dada del formato correcto (tanto las rutas felices como las infelices: ¿qué sucede si se recibe una ID de publicación no válida? ¿Qué sucede si el usuario ha usado sus 25 votos a favor en un día? ¿Incrementa el número de votos correctamente?)
- Pruebe su javascript para que responda correctamente cuando se le da un blob de JSON en el formato correcto (¿actualiza la imagen +1 para mostrar que se ha utilizado? (Pensando en Google+ aquí ...) ¿Muestra el mensaje de agradecimiento? Etc. )
Todo esto no afecta el comportamiento, pero cuando haya terminado de lidiar con las pruebas de nivel inferior, será trivial completar la definición de paso para votar una publicación. Puede ser tan simple como click_link '+1'. Y el resto de los pasos son resultados de pruebas, lo que nuevamente debería ser sencillo de hacer. Y cuando haya terminado, entonces sabrá que su función está completa y terminada. Si el comportamiento necesario cambia, puede modificar su función, de lo contrario puede modificar su código de implementación con total seguridad.
Espero que esto tenga sentido. Todo ha estado fuera de mi alcance, pero creo que demuestra la diferencia entre BDD y TDD, y por qué Cucumber y RSpec satisfacen diferentes necesidades.