¿El BDD es realmente aplicable en la capa UI?

Question

BDD es una "fuera de" metodología, que según tengo entendido, significa que comienza con lo que sabe. Escribes tus historias y escenarios, y luego implementas los objetos de dominio más externos, moviéndote "hacia adentro" y "deliberadamente" descubriendo colaboradores a medida que avanzas: hacia abajo a través de capas de servicio, capas de dominio, etc. Para un colaborador que aún no existe, te burlas (o "falsas") hasta que lo haces. (Estoy robando algunos de estos términos directamente de Dan North y Kent Beck).

Entonces, ¿cómo encaja una interfaz de usuario en esto?

Tomando prestado de uno de Norte de blog entries, que vuelve a escribir esto:

Given an unauthenticated user 
When the user tries to navigate to the welcome page 
Then they should be redirected to the login page 
When the user enters a valid name in the Name field 
And the user enters the corresponding password in the Password field 
And the user presses the Login button 
Then they should be directed to the welcome page 

en esto:

Given an unauthenticated user 
When the user tries to access a restricted asset 
Then they should be directed to a login page 
When the user submits valid credentials 
Then they should be redirected back to the restricted content 

Él hace esto para eliminar el lenguaje de dominios que no son relevantes, uno de los cuales es la interfaz de usuario ("Campo de nombre", "Campo de contraseña", "Botón de inicio de sesión"). Ahora la IU puede cambiar y la historia (o más bien, la intención de la historia ) no se rompe.

Entonces, cuando escribo la implementación de esta historia, ¿uso la IU o no? ¿Es mejor iniciar un navegador y ejecutar "el usuario envía credenciales válidas" a través de una prueba de Selenium, o conectarse directamente a la implementación subyacente (como un servicio de autenticación)? Por cierto, estoy usando jBehave como mi framework BDD, pero podría ser igual de fácil que Cucumber, rSpec, o un número de otros.

Tiendo a no probar UI de manera automatizada, y soy cauteloso con las herramientas de automatización GUI como Selenium porque creo que las pruebas (1) pueden ser demasiado frágiles y (2) se ejecutan donde el costo de ejecución es la mayor. Así que mi inclinación es probar manualmente la interfaz de usuario para la estética y la usabilidad y dejar la lógica de negocios en capas más bajas y más fáciles de usar. (Y posiblemente capas menos propensas a cambiar.)

Pero estoy abierto a ser convertido en esto. Entonces, ¿BDD para UI o no?

PS. He leído todas las publicaciones de SO que pude encontrar sobre este tema, y ​​ninguna realmente aborda mi pregunta. This one se acerca más, pero no estoy hablando de separar la interfaz de usuario en una historia separada; más bien, estoy hablando de ignorarlo por completo para los propósitos de BDD.

Answer 1

La mayoría de las personas que usan herramientas BDD automáticas lo utilizan en la capa de IU. He visto algunos equipos llevarlo a la siguiente capa, el controlador o la capa del presentador, porque su interfaz de usuario cambia con demasiada frecuencia. Un equipo automatizado desde la interfaz de usuario en su sitio orientado al cliente y desde el controlador en el sitio de administración, ya que si algo se rompe, podrían solucionarlo fácilmente.

Mayormente BDD está diseñado para ayudarlo a tener conversaciones claras y sin ambigüedades con sus partes interesadas (o para ayudarlo a descubrir los lugares donde todavía existe ambigüedad) y llevar el lenguaje al código. Las conversaciones son mucho más importantes que las herramientas.

Si usa el lenguaje que utiliza la empresa al escribir sus pasos, y los mantiene en un nivel alto como sugiere Dan, deberían ser mucho menos frágiles y fáciles de mantener. Estos escenarios no son realmente pruebas; son ejemplos de cómo usará el sistema, que puede usar en una conversación y que le dan pruebas como un buen subproducto. Tener las conversaciones en torno a los ejemplos es más importante que la automatización, independientemente del nivel en que lo haga.

Yo diría que, si su UI es estable, pruebe la automatización, y si no le funciona, baje a un nivel inferior o asegúrese de que tiene suficientes pruebas manuales. Si prueba estética de todos modos, ayudará (¡y nunca usará la automatización para probar la estética!) Si su UI no es estable, no la automatice, solo está agregando compromiso a algo que probablemente va a suceder. cambio, y la automatización en ese caso lo hará más difícil.

Answer 2

Soy nuevo en BDD, pero encontré el sitio cuke4ninja para ayudar en este sentido. Lo que ellos sugieren (mi interpretación) es que tengas tus definiciones de pasos que son de alto nivel y UI independientes, que llaman a una clase de "flujo de trabajo" que agrupa los detalles como "hacer clic en este botón", "poblar este campo" en un método que capture el flujo de trabajo bajo prueba, que llama a una clase de "controlador de pantalla" que maneja la automatización de UI para esa pantalla en particular. De esta forma, todo el código de automatización de la interfaz de usuario se abstrae de las definiciones de pasos y se encuentra en una sola ubicación, y si la interfaz de usuario cambia, solo tiene que cambiar el código en el "controlador de pantalla" en lugar de todas las pruebas múltiples. Here es la página relevante donde se discute.