¿Cómo elegir entre diferentes tipos de prueba con SpecFlow, Cucumber u otro marco de prueba de aceptación de BDD?

Question

estoy mirando ejemplos SpecFlow, y es muestra de MVC contiene varias alternativas para las pruebas: pruebas

• de aceptación en base a la validación de los resultados generados por los controladores;
• Pruebas de integración usando MvcIntegrationTestFramework;
• Pruebas de aceptación automatizadas con Selenium;
• Pruebas de aceptación manual cuando se solicita al comprobador que valide manualmente los resultados.

debo decir que estoy muy impresionado con lo bien SpecFlow ejemplos están escritos (y me las arreglé para ejecutarlos en cuestión de minutos después de la descarga, sólo tenía que configurar una base de datos e instalar selenio servidor de control remoto). Mirando las alternativas de prueba, puedo ver que la mayoría de ellos se complementan entre sí en lugar de ser una alternativa. Puedo pensar de las siguientes combinaciones de estas pruebas:

• controladores se prueban en estilo TDD en lugar de utilizar SpecFlow (I creen Dado/cuando/luego tipo de pruebas debe ser aplicado en superior, de extremo a extremo nivel sino que debe proporcionar una buena cobertura de código para los componentes respectivos;
• MvcIntegrationTestFramework es útil cuando se ejecutan las pruebas de integración durante las sesiones de desarrollo, estas pruebas son también parte de las construcciones diarias;
• Aunque las pruebas a base de selenio son automatizados, son lentos y están principalmente para comenzar durante las sesiones de QA, para validar rápidamente que no haya una lógica rota en las páginas y el flujo de trabajo del sitio;
• Las pruebas de aceptación manual cuando se solicita al probador para confirmar la validez del resultado son principalmente para verificar el aspecto de la página.

Si utiliza SpecFlow, pepino u otro marco de prueba de aceptación BDD en que el desarrollo Web, puede usted por favor compartir sus prácticas con respecto a la elección entre los diferentes tipos de pruebas.

Gracias de antemano.

Answer 1

Todo es comportamiento.

Dado un contexto particular, cuando ocurre un evento (dentro de un alcance particular), entonces debe ocurrir algún resultado.

El alcance puede ser una aplicación completa, una parte de un sistema o una sola clase. Incluso una función se comporta de esta manera, con las entradas como contexto y la salida como resultado (¡también puede usar BDD para el lenguaje funcional!)

Tiendo a utilizar los marcos de unidad (NUnit, JUnit, RSpec, etc.) en una clase o nivel de integración, porque la audiencia es técnica. Algunas veces documentaba el Dado/Cuándo/Luego en comentarios.

En un nivel de escenario, trato de averiguar quién realmente quiere ayudar a leer o escribir los escenarios. Incluso las partes interesadas de negocios pueden leer texto que contiene algunos puntos y corchetes, por lo que la razón principal para tener un marco de lenguaje natural como MSpec o JBehave es si quieren escribir escenarios ellos mismos, o mostrarlos a personas que realmente se desanimen por los puntos y corchetes.

Después de eso, miro cómo funcionará el framework con el sistema de compilación, y cómo le daremos la capacidad de leer o escribir según corresponda a los interesados.

Here's an example I wrote para mostrar el tipo de cosas que puede hacer con escenarios utilizando DSL simples. Esto está escrito en NUnit.

Here's an example in the same codebase mostrando Given, When, Then en el nivel de clase de los comentarios de ejemplo.

Resumiendo los pasos que hay detrás, luego coloco pantallas o páginas detrás de ellos, luego en las pantallas y páginas llamo al marco de automatización que estoy usando, que podría ser Selenium, Watir, WebRat, Microsoft UI Automation, etc.

El ejemplo que proporcioné es en sí una herramienta de automatización, por lo que los escenarios demuestran el comportamiento de la herramienta de automatización al demostrar el comportamiento de una interfaz gráfica de usuario falsa, en caso de que resulte confuso. Espero que ayude de todos modos!

Answer 2

Dado que las pruebas de aceptación son un tipo de pruebas funcionales, el objetivo general es probar su aplicación con ellas de principio a fin. Por otro lado, es posible que deba considerar la eficiencia (cuánto esfuerzo se requiere para implementar la automatización de prueba), el mantenimiento, el rendimiento y la confiabilidad de la automatización de prueba. También es importante que la automatización de pruebas pueda adaptarse fácilmente al proceso de desarrollo, de modo que sea compatible con un tipo de enfoque de "probar primero" (para admitir el desarrollo externo).

Así que esto es una compensación, que puede ser diferente para cada situación (es por eso que proporcionamos las alternativas).

Estoy bastante seguro de que hoy la opción más adecuada es probar en la capa del controlador. (Tal vez más tarde, a medida que evolucionen los marcos de automatización de UI y UI, esto cambiará).