c# - examples - specflow net core

BDD en el exterior(con flujo de especificaciones)

Question

Soy nuevo en BDD, pero me pareció muy interesante y quiero desarrollar mi próximo proyecto utilizando BDD. Después de buscar en Google y ver screencasts, todavía tengo muchas preguntas sobre la BDD en la vida real.

1. ¿Escenarios declarativos o imperativos?

La mayoría de los escenarios dados cuando ocurrieron fueron escritos en términos de IU (imperativo).

Scenario: Login
     Given I am on the Login-page
     When I enter ''AUser'' in the textbox ''UserName''
       And I enter ''APassword'' in the textbox ''Password''
       And I click the ''Login'' button
     Then I should see the following text ''You are logged in''

Encontré esas pruebas extremadamente frágiles y no dicen nada sobre el valor comercial de hacer clic en los botones. Creo que es una pesadilla mantener. ¿Por qué la mayoría de los ejemplos utilizan escenarios imperativos?

Scenario: Login (declarative)
     Given I am not logged in
     When I log in using valid credentials
     Then I should be logged in

Si prefiere el estilo declarativo, ¿cómo describe cosas como ''Página de inicio'' o ''Página de productos''?

• Consejos para escribir buenas especificaciones.

2. Ejercicio UI o no?

La mayoría de las implementaciones de pasos que vi utilizaron WatiN, White o algo así para implementar escenarios desde el punto de vista del usuario. Iniciando navegador, haciendo clic en los botones. Creo que es extremadamente lento y quebradizo. Bueno, puedo usar algo como el objeto Page para hacer que las pruebas sean menos frágiles. Pero eso es otra cantidad de trabajo. Especialmente para aplicaciones de escritorio con IU compleja.

¿Cómo implementa escenarios en proyectos de la vida real, ejercitando UI, o probando controladores / presentadores?

• La mejor manera de aplicar BDD

3. ¿Base de datos real o no?

Cuando se implementa una parte dada del escenario, a menudo necesita que algunos datos estén en el sistema (por ejemplo, algunos productos para la aplicación de la tienda). ¿Cómo implementa esa parte: agregar datos a la base de datos real (pruebas completas de extremo a extremo) o proporcionar apéndices de repositorio a los controladores?

Esperando respuestas experimentadas!

ACTUALIZACIÓN: Se agregaron enlaces útiles sobre preguntas.

Answer 1

1. Declaritive es la forma correcta, OMI. Si estás hablando de los nombres de archivo .aspx de la página, lo estás haciendo mal. El propósito de la historia es facilitar la comunicación entre desarrolladores y no desarrolladores. Los no desarrolladores no se preocupan por products.aspx, se preocupan por una lista de productos. Su sistema hace algo en lo que los no desarrolladores encuentran valor. Esto es lo que está intentando capturar.

2. Bueno, las historias cuentan las características de alto nivel que necesitas implementar. Es lo que tu sistema debe hacer. La única manera de saber realmente si has hecho esto es, de hecho, ejercer la interfaz de usuario. Las historias de BDD SpecFlow para mí no reemplazan las pruebas unitarias, sino que son las pruebas de integración. Si rompe esto, ha roto el valor que la empresa obtiene de su software. Las pruebas unitarias son detalles de implementación que a sus usuarios no les importan y solo prueban cada pieza de forma aislada. Eso no puede decirle si A y B realmente trabajan juntos todo el tiempo (en teoría debería, en la práctica, cosas interesantes [leídas: inesperado] suceden cuando en realidad tiene las dos partes jugando entre sí). Las pruebas automatizadas de extremo a extremo también pueden ayudarlo con su control de calidad. Si un área funcional se rompe, usted lo sabe, y pueden pasar su tiempo en otras áreas de la aplicación mientras determina qué rompió las pruebas de integración.

3. Esta es una pregunta difícil. Hemos hecho un enfoque híbrido. Usamos la base de datos (las pruebas de integración después de todo probamos el funcionamiento del sistema como una cosa, en lugar de los componentes individuales), pero en lugar de restablecer las configuraciones todo el tiempo, usamos Deleporter para reemplazar nuestros repositorios con Moqs cuando sea necesario. Parece funcionar bien, pero ciertamente hay ventajas y desventajas de cualquier manera. Creo que todavía estamos resolviendo esto en gran medida nosotros mismos.

Answer 2

En lugar de mencionar una página por nombre, describa lo que representa, por ejemplo,

Scenario: Customers logs in successfully

  When I log in
  Then I should see an overview of ACME''s top selling products

Puede probar directamente contra modelos o API subyacentes, pero cuanto más haga esto, más riesgo tendrá de no detectar un problema de integración. Un enfoque es equilibrar las cosas con un pequeño número de pruebas de pila completa, y un número mayor que prueba solo entre dos capas.

Answer 3

Edición : Encontré este artículo que acaba de describir el concepto de limitarse a hablar solo de dominios específicos para evitar escenarios frágiles .

Su punto principal es que el número mínimo de dominios de los que puede hablar es el dominio del problema y el dominio de la solución. Si está hablando de algo fuera de esos dos dominios, entonces involucra a muchas partes interesadas, introduce demasiado ruido y hace que sus escenarios sean frágiles.

También menciona que un modelo "declarativo" o "imperativo" absoluto es un mito. Habla de un modelo cognitivo llamado "fragmentación", y dice que en cualquier nivel de abstracción, puede "fragmentar" o "fragmentar". Esto significa que puede obtener más explícito (¿cómo?) O más meta (¿qué o por qué?). Se parte de un modelo imperativo preguntando "¿qué estamos haciendo?" Te molestas diciendo "¿cómo haremos esto?" Así que supongo que no me obsesionaría demasiado con lo declarativo y lo imperativo: no te llevará a ninguna parte en lo que respecta a este problema.

Lo que lo llevará a algún lugar es averiguar a qué dominios pertenece cada término, posiblemente identificando qué parte interesada es el experto para el dominio al que pertenece. Una vez que haya identificado todos los dominios, puede elegir los términos relacionados que están en uno. de los dominios más destacados del escenario, o elimine las declaraciones no adecuadas por completo. Si eso no es suficiente, puede dividir, especificar más o mover el escenario para que pueda satisfacer estos requisitos.

Por cierto, también usa el escenario de inicio de sesión en una interfaz de usuario, por lo que tiene una orientación concreta :)

Antes de la edición : (parte de esto todavía se aplica. Las preguntas "DB o no DB" y "UI o no UI" no están relacionadas)

1 - ¿Escenarios declarativos o imperativos?

Declarativo cuando se puede, aunque el imperativo tiene algún valor (en algunos puntos del ciclo de vida del proyecto).

Imperativo es una forma más fácil de pensar para los evaluadores y analistas de negocios que no están tan familiarizados con la teoría de la información y el diseño. También es más fácil pensar antes en un proyecto, antes de que haya definido el dominio del problema y los flujos de trabajo. Puede ser útil para el pensamiento exploratorio.

Declarativo está menos sujeto a cambios con el tiempo. Dado que una GUI es la parte de una aplicación más sujeta a deserción a un capricho, esto es extremadamente valioso. Es más fácil pensar una vez que haya definido su dominio de problemas y flujos de trabajo, y se centre más en los conceptos relacionales. Es un modelo más estable y de aplicación más general.

Si escribe casos de prueba con un modelo genérico y declarativo, puede implementarlos utilizando cualquier combinación de automatización GUI de la aplicación completa, pruebas de integración o pruebas unitarias.

¿Cómo describe cosas como ''Página de inicio'' o ''Página de productos''?

No estoy seguro de que lo haría en el nivel básico de características y requisitos. Puede crear subcaracterísticas y requisitos que describan los detalles de la implementación, como flujos de trabajo de IU específicos. Si está describiendo una parte de una UI, entonces debería definir una característica / requisito de UI.

2 - Ejercicio UI o no?

Ambos.

Creo que es extremadamente lento y quebradizo.

Sí lo es. Realice todos los escenarios / requisitos de alto nivel con la interfaz de usuario y la integración completa de la base de datos, pero no ejerza cada ruta de código individual con la automatización de la interfaz de usuario de extremo a extremo, y ciertamente no los casos de borde. Si lo hace, pasará más tiempo haciendo que funcionen, y mucho menos tiempo probando su aplicación.

Puede diseñar su aplicación de manera que pueda realizar pruebas de integración de menor costo, incluidas las pruebas basadas en UI de una sola pieza. Las pruebas unitarias también son valiosas.

Pero cuantas menos pruebas de integración realices, más errores de bofetadas te vas a perder. Puede que sea más fácil escribir pruebas unitarias, y ciertamente serán menos frágiles, pero, por definición, estará probando menos de su aplicación.

3 - ¿Base de datos real o no?

Ambos.

Las pruebas de integración de extremo a extremo de alto nivel deben realizarse con el sistema completo en su lugar. Esto incluye una base de datos real, que ejecuta sus pruebas con cada sistema en un servidor diferente, etc.

Mientras más bajo sea el nivel, más defiendo los objetos simulados.

• Las pruebas unitarias solo deben probar las clases individuales.
• Las pruebas de integración de nivel medio deben evitar dependencias costosas, frágiles e impactantes, como el sistema de archivos, bases de datos, la red, etc. Trate de probar la implementación de esas dependencias frágiles e impactantes con pruebas unitarias y pruebas de extremo a extremo solamente.