testing - scenario - ¿Es BDD realmente aplicable en la capa UI?
command to install and run cucumber test is (3)
La mayoría de las personas que usan herramientas BDD automatizadas lo usan en la capa UI. He visto a algunos equipos llevarlo a la siguiente capa hacia abajo (la capa de controlador o presentador) porque su IU cambia con demasiada frecuencia. Un equipo automatizado desde la interfaz de usuario en su sitio de atención al cliente y desde el controlador en el sitio de administración, ya que si algo se rompe, podrían arreglarlo fácilmente.
En su mayoría, 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 la ambigüedad!) Y llevar el lenguaje al código. Las conversaciones son mucho más importantes que las herramientas.
Si usa el lenguaje que usan los negocios cuando escribe 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 vas a usar el sistema, que puedes usar en la conversación y que te 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 el que lo haga.
Yo diría que, si su UI es estable, pruebe la automatización, y si no funciona para usted, descienda a un nivel inferior o asegúrese de que tenga suficientes pruebas manuales. Si está probando la estética de todas formas, eso ayudará (¡y nunca, nunca use la automatización para probar la estética!) Si su UI no es estable, no la automatice, solo está agregando compromiso a algo que sabe que probablemente vaya a El cambio, y la automatización en ese caso lo hará más difícil.
BDD es una metodología de " entrada y salida " , que, como la entiendo, significa que comienzas con lo que sabes. Escribe sus historias y escenarios, y luego implementa los objetos de dominio más externos, moviéndose "hacia adentro" y "deliberadamente" descubriendo colaboradores a medida que avanza hacia abajo a través de las capas de servicio, capas de dominio, etc. Para un colaborador que aún no existe, te burlas (o "lo simulas") 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 un préstamo de una de las entradas de blog de North, reescribe 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
dentro de 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
Hace esto para eliminar el idioma de los dominios no 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 interfaz de usuario 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 interfaz de usuario o no? ¿Es mejor abrir 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 marco BDD, pero podría ser igual de fácil de ser Pepino, rSpec o varios otros.
Tiendo a no probar la UI de forma automática, 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) ejecutarse donde el costo de ejecución es 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 empresarial a capas más bajas, más fácilmente automatizables. (Y posiblemente las capas tienen menos probabilidades de cambiar.)
Pero estoy abierto a ser convertido en esto. Entonces, ¿es BDD para UI o no?
PD. He leído todas las publicaciones sobre SO que pude encontrar sobre este tema, y ninguna realmente responde a mi pregunta. Este 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 a los efectos de la BDD.
Soy nuevo en BDD, pero encontré el sitio cuke4ninja para ayudar en este sentido. Lo que sugieren (mi interpretación) es que tiene sus definiciones de pasos que son de alto nivel y UI agnósticas, que llaman a una clase de "flujo de trabajo" que agrupa los detalles como "haga clic en este botón", "rellene este campo" en un método que captura el flujo de trabajo bajo prueba, que llama a una clase de "controlador de pantalla" que maneja la automatización de la interfaz de usuario para esa pantalla en particular. De esa manera, todo el código de automatización de la interfaz de usuario se extrae de las definiciones de pasos y se encuentra en una única 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 está la página relevante donde se discute.
¿Qué describe la BDD?
En los equipos que siguen un desarrollo guiado por el comportamiento (BDD), los criterios de aceptación (también conocidos como reglas) deben describir "lo que hace el sistema" en lugar de "cómo lo hace el sistema".
Entonces, ¿dónde se capturan los detalles de UI / UX en un equipo que sigue a BDD?
En los equipos que usan BDD, los detalles de la capa Interfaz de usuario (UI) y Experiencia de usuario (UX) (botones, clics, animaciones, etc.) no deben incluirse como Criterios de aceptación (también conocido como Reglas) en formato de texto, bajo un ticket (por ejemplo, emitido con una herramienta de Ticketing del software tal como JIRA, GitLab, etc). En su lugar, deben incluirse dentro de las pantallas de diseño (wireframes, viaje del usuario, pantallas individuales, etc.). Por ejemplo, las notas de texto se pueden incrustar en las pantallas de diseño con anotaciones, o simplemente como comentarios junto a las pantallas.