ruby on rails - Prueba de integración vs aceptación... ¿Qué es el pepino/filete?

ruby-on-rails rspec

Question

Para las pruebas de integración de mi aplicación web Rails, uso Steak (algo como pepino). Las especificaciones de Filete están en una carpeta llamada especificación / aceptación. ¿Son los filetes / pepinos ahora para pruebas de integración o aceptación? Siempre pensé que esto es algo diferente.

Answer 1

Primero, una nota sobre la terminología: el término prueba de integración es un tanto vago en la comunidad TDD. Dependiendo de si vienes de Java o Rails (con Test :: Unit), puedes entender diferentes cosas por él. En Rails (with Test :: Unit) las pruebas de integración son las pruebas que prueban su pila completa, mientras que las pruebas funcionales serían las que prueban su controlador. La mayoría de la gente en la comunidad de Java (al menos por mi observación) pensaría que es al revés. Personalmente, prefiero llamar a las pruebas de aceptación de las pruebas de extremo a extremo, mientras que las pruebas llegan a varias capas del sistema (pero no a todas): pruebas de integración . En definitiva, eso depende bastante de la cultura en la que se encuentre.

En cuanto a Cucumber y Steak, ambos son marcos que permiten un estilo de desarrollo conocido como Behavior-Driven Development (o BDD, por sus siglas en inglés). El punto es que tienes dos niveles de pruebas:

• Pruebas de extremo a extremo , que prueban a través de la pila completa: simulan un navegador, pasan por los controladores y llegan a la base de datos. El pepino y el filete se ajustan a este nicho.
• Pruebas unitarias , que prueban una pequeña parte de la funcionalidad de forma aislada (por lo general, una sola clase, burlándose de sus colaboradores). Aquí es donde encaja RSpec.

En BDD, comienza con una prueba de extremo a extremo que falla (con mucho cariño se conoce como "engranaje superior"), y luego comienza a implementar la prueba de funcionalidad primero con RSpec (el "engranaje inferior"), hasta que obtiene el final a fin de pasar la prueba. De esta manera, la prueba de extremo a extremo está dirigiendo las pruebas unitarias, que a su vez están impulsando su implementación. El principal beneficio es evitar el desplazamiento del alcance: no terminas implementando una funcionalidad visible para el usuario que no necesitas (ya que no escribes una prueba de extremo a extremo).

Si desea obtener más información sobre esto, he escuchado que el artículo de Wikipedia sobre desarrollo impulsado por el comportamiento es sorprendentemente bueno. Además, el libro RSpec.

Por lo tanto, tanto Cucumber como Steak son marcos que le permiten escribir pruebas en la "marcha superior". La diferencia está en el estilo: Cucumber te hace escribir tus pruebas en lenguaje natural. Esto tiene varios beneficios.

• Las personas de negocios pueden leer las pruebas : si bien no puede esperar que los que no son programadores las escriban, hacen un gran trabajo para comunicar lo que pretende hacer. Puede escribir la función (la prueba de pepino primero) y mostrarla al cliente para obtener algún comentario sobre si esto es lo que realmente quiere. He encontrado esto muy útil.
• Las características de pepino se comunican mejor con la intención , ya que puedes usar todo el poder del idioma inglés (o cualquier otro, realmente), puedes comunicar por qué esta característica es relevante y cómo los usuarios logran su objetivo en un nivel que Ruby no permitirá. usted a
• Pepino ayuda a descubrir el lenguaje ubicuo : el dominio incluye una gran cantidad de términos que vuelan en las conversaciones con los clientes. Pepino le permite descubrirlos y capturarlos antes de comenzar a implementar la función. Y todo está basado en pruebas.
• Las características de pepino son algo más altas , lo que hace que las características (pero no las definiciones de pasos) sean más independientes de la interfaz. De esta manera, si es necesario cambiar la interfaz, no tendrá que volver a trabajar las características.

Las desventajas incluyen que es un poco difícil aprender a aplicarlo bien y que tienes que escribir un poco más (tanto características como definiciones de pasos). Descubrí que el segundo no es realmente un problema si lo has estado haciendo durante un tiempo, ya que obtienes una serie de pasos reutilizables que te permiten escribir las siguientes funciones más rápido.

El bistec, por otro lado, es más sencillo y es rubí. Pierde todos los beneficios del uso del inglés, pero puede escribir menos y se ejecutará más rápido (un poco).

En la línea inferior, utiliza ambos para escribir las pruebas de extremo a extremo que impulsan el desarrollo.