Común problema de desarrollo software
-
Alejamiento entre usuario y desarrollo
- incumplimiento de requisitos del usuario
- la funcionalidad del software final no es lo que quiere usuario
- diferencia entre uso del lenguaje
-
Alejamiento entre testing y desarrollo
- Separación entre testing y desarrollo
- ciclo de desarrollo es demasiado largo
- bajo porcentaje de automatización
Solución
- Testing throughout the Software Life Cycle: prueba unitaria, prueba de integración, prueba de sistema
- Testing automátizada
-
Integración continua
- Check-in continua
- Build continua
- Deploy continua
-
Test continua
- Testing para cada check-in
- Una prubea de integración por día
- Una prueba de sistema por día
Test Driven Development
Una práctica de desarrollo software que se basa en escribir las pruebas primero y luego refactorizar. En primer lugar, se escribe una prueba y se verifica que las pruebas fallan. A continuación, se implementa el código que hace que la prueba pase satisfactoriamente. Una vez pase la prueba unitaria refactorizamos y volvemos a repetir el ciclo.
- Elegir un requisito
- Escribir una prueba
- Verificar que la prueba falla
- Escribir la implementación
- Ejecutar las pruebas automatizadas
- Eliminación de duplicación
- Actualización de la lista de requisitos
Behauvior Driven Development
(Behavior-Driven Development - BDD) deriva de TDD, y combina los principios de domain-driven design con ideas del uso de un lenguaje común (domain-specific language - DSL) para elaborar el testing. Utiliza sintaxis como Given, When, Then para expresar el comportamiento y salida esperada. Las pruebas se escriben usando historia de usuario, el que ya esta escrito en un documento dedicado. Un problema común de TDD es el test depende de la implementation la función. En BDD afrontamos este problema en testear el comportamiento de la función sin tener en cuenta la detalle de su implementación.
Especificaciones del comportamiento
El comportamiento deseado deber ser especificado por el DSL(Domain-Specific-Language) por ejmplo Gherkin, que usa 5 sentencias
Fuature: Un título claro y explícito de la
historia
Una pequeña sección de introducción que especifique
- quién
- qué efecto se quiere
- qué beneficia la parte interesada a partir de este efecto
Criterios de aceptación o escenarios
Scenario:
Una descripción de un ejemplo específico de la feature
- Comienza a especificar la condición inicial con la sentencia Given:Precondición, puede consistir en una causa o varias
- Después declara cuál evento causa el inicio del escenario When:Condición
- Finalmente, declara el resultado esperado, en una o más cláusulas Then:Postcondición
Acceptance Test Driven Development
Es una práctica en la que todo el equipo analiza y determina de forma colaborativa los criterios ejemplificativos de aceptación, y son divididos en un conjunto de pruebas antes de comenzar el desarrollo.
Diferencia
Diferencia | ATDD | TDD | BDD |
---|---|---|---|
Colaboradores | Cliente | Desarrollador y Tester | ATDD + TDD |
Objetivo | Participa los usuarios en la fase de diseño | Una practica de desarrollo | Unit tester y negocio con un lenguaje común |
Documento | Criterio de aceptación ejemplificativos | Documento de requisito | documento escrito en lenguaje Gherkin |
Automatización | No es necesario | necesario | necesario |
Testing | Cada historia de usuario | Cada funcionalidad | Cada historia de usuario |