DHH en pruebas unitarias: ¿es innecesario el RSpec innecesariamente?

Question

Soy suscriptor de Ruby Inside, ya que estoy particularmente interesado en Rails. Ayer, el creador de Rails, David Heinemeier Hansson, dijo que simplemente está usando test/unit. Lo entendería, ya que es interno de Rails, pero parece haber dado una opinión firme. Él cree que RSpec y Cucumber son innecesariamente complicados.

Normalmente no prestaría mucha atención, pero depende de quién diga algo. Respeto mucho a Hansson y su opinión me hizo pensar. Cuando comencé con Rails, nunca me fijé realmente en la prueba/unidad. Solo RSpec y Cucumber.

Y es por eso que quiero su conocimiento. ¿Crees que RSpec es realmente complicado por poco valor agregado? ¿Escribir prueba/unidad requiere menos tiempo y esfuerzo?

Answer 1

Mi recomendación sería usar Shoulda (extiende Test :: Unit) o ​​RSpec con Capybara, y -no- Cucumber.

Creo que vale la pena usar RSpec o Shoulda para contextos anidados. Sin embargo, RSpec es definitivamente pesado (quizás con sobrepeso), y estoy en la cerca con eso por esa razón.

Pepino, finalmente he llegado a entender, es más complicado de lo que generalmente vale la pena. Puede lograr lo que necesita de manera más simple y sólida con simples pruebas de integración y Capibara. Recuerde: ¡Capibara! = Pepino, y Capibara es bastante capaz por sí mismo.

Shoulda es agradable, porque simplemente agrega conveniencias al marco estándar de Test :: Unit, y por lo tanto es mucho más liviano que RSpec (técnicamente, cada uno resuelve un conjunto diferente de problemas, pero ambos proporcionan capacidades de contexto anidado) RSpec tiene la ventaja de hacer que las aserciones se lean de forma más natural, y también generar mensajes de error más útiles en muchos casos, sin la necesidad de escribir argumentos de mensaje en las aserciones.

Además, recuerde que Cucumber en realidad no necesita RSpec, por lo que si desea seguir usando Cucumber, puede hacerlo con solo Test :: Unit. Las opciones abundan.

Answer 2

Todo se trata de semántica. RSpec y Test :: Unit son funcionalmente similares. Personalmente, siempre he preferido RSpec porque me pareció más natural escribir pruebas para usarlo. También me gusta la simplicidad de escribir custom matchers, y las correspondencias predeterminadas proporcionadas son útiles.

El pepino es una bestia completamente diferente. Sí, es bastante engorroso y se vuelve difícil de mantener si no organiza correctamente sus definiciones de pasos, pero tiene un caso de uso muy sólido y es cuando su cliente está escribiendo sus especificaciones.

He trabajado en proyectos en los que el cliente ha estado escribiendo Escenarios de pepino junto con uno de nuestro equipo de control de calidad. Como persona no técnica, es una forma muy accesible y natural de especificar historias de usuario en el código. Cucumber realmente nos ayudó a caminar cuando se trataba de seguir nuestras prácticas ágiles. La calidad del producto final se benefició de eso, pero no, yo no como pepino como desarrollador :)

Answer 3

Es una cuestión de gusto personal.

Me gusta escribir pruebas fáciles de pepino sin preocuparme por los detalles. Estoy probando las rutas "felices" de mi aplicación. (portátil, comprensible, lento)

Dejo los detalles a Prueba/Unidad.(Fácil, rápido)

se necesita más tiempo para entender:

get :products, :session => @session_id_for_product_banana 
assert_select "table" do 
    assert_select "td#name", "Banana" 
end 

en lugar de

When I go to the banana page 
Then I should see "Banana" 

seguro de que esas pruebas no son iguales, pero a quién le importa si la "banana" está en un div o una tabla o no tiene el html-id correcto.

No me gustan las pruebas funcionales porque después de refactorizar, las identificaciones podrían haberse ido, la expectativa de la sesión podría cambiarse. Si ese es el caso, tendrá que refactorizar su código Y pruebas. Si usa pepino, no tendría que cambiar su escenario.