TESTS UNITARIOS. keep the bar green to keep the code clean

Transcripción

1 TESTS UNITARIOS keep the bar green to keep the code clean

2 Para qué hacer tests unitarios? Es imposible hacer software libre de defectos. Tiempo del desarrollador: Diseño Análisis Debug Desarrollo Los tests unitarios aumentan la productividad, mejoran la calidad y hacen que el software sea más confiable.

3 Pruebas que podemos hacer Testing Tests del desarrollador Tests automatizados Tests unitarios

4 Los Tests Unitarios deben (I) Ayudar a mejorar la calidad Ayudar a entender el sistema bajo prueba (SUT) Reducir (no introducir) riesgos Tests como especificación Tests como documentación Tests como red de seguridad Repelentes de bugs No causar daño Localización de defectos

5 Los Tests Unitarios deben (II) Ser fáciles de ejecutar Ser fáciles de escribir y mantener Requerir mínimo mantenimiento, mie ntras el sistema evoluciona Automáticos Simples Robustos Self-Checking Expresivos Repetibles Separación de incumbencias

6 Principios (I) Escribir los tests primero (TDD) Diseñar para ser testeable Usar la puerta de entrada primero Comunicar intención No modificar el «sistema bajo prueba» (SUT) Mantener los tests independientes Aislar el SUT (evitar sensibilidad al contexto)

7 Principios (II) Minimizar la superposición de tests Minimizar el código no testeable Mantener la lógica del test fuera del código productivo Verificar una condición por test Separar incumbencias por test Asegurar esfuerzo y responsabilidad proporcionales

8 Qué tipos de tests podemos automatizar? Tests por funcionalidad De aceptación (Pruebas de cliente) De componentes (Diseño del sistema) Unitarios (Diseño del código) Tests transversales a la funcionalidad Usabilidad Exploratorios (Consistencia) De interfaces (Prototipos / Integración)

9 Con qué objetivos automatizamos? Deben estar alineados con todos los objetivos de Calidad. Deseamos automatizar las pruebas regresivas? Deseamos realizar Integración Continua en nuestro Proceso de Desarrollo? Estamos buscando resolver un ítem específico de Aseguramiento de Calidad?

10 Estrategias para automatizar tests Comenzar a automatizar tests desde el inicio del proyecto Elegir la herramienta adecuada xunit frameworks Robot user Scripted UI Seleccionar los casos de prueba a automatizar

11 Frameworks Java junit TestNG.Net MSTest MBUnit NUnit xunit.net Incorporada en Visual Studio Otros HttpUnit DBUnit

12 Organizando los Tests Unitarios xunit Test Suite Test Fixture

13 Test Fixture [Set Up] [Tear Down] Crear el SUT y sus dependencias Inicializarlas en el estado requerido Ejecutar el SUT Verificar Finalizar

14 Estrategias para el Test Fixture Estrategia Set Up Tear Down Set Up / Tear Down Triggering Transient Fresh X Persistent Fresh X X Shared X X X

15 El código es testeable? Dependencias Configuración Estados internos TDD

16 Cómo testear? Testear el camino feliz Verificar las salidas directas del camino feliz Set up de un estado pre-test simple del SUT Ejecutar el SUT, llamando al método a testear Llamar métodos de assert sobre las respuestas del SUT Llamar métodos de assert sobre el estado post-test Verificar caminos alternativos Verificar el comportamiento de las salidas indirectas Optimizar la ejecución y mantenibilidad Variar los argumentos del método SUT Variar el estado pre-test del SUT Controlar las salidas indirectas del SUT via un Test Stub Usar Mock Objects o Test Spies para interceptar y verificar las llamadas salientes a métodos Hacer que los tests corran rápido Hacer que sean fáciles de entender y mantener Diseñar el SUT para ser testeable Reducir el riesgo de bugs no percibidos

17 Organizando los tests Clase de Test por: Clase Funcionalidad Fixture Reutilización de código de test Test superclass Test helper Convenciones de nombres Minimizar tamaño de métodos de test Test Suites Independencia de tests en producción

18 Recursos de verificación Fakes Reemplazan componentes de los cuales depende el SUT, por una implementación liviana Mejoran la performance de los tests Mocks Reemplazan un objeto del SUT para verificar si esta siendo correctamente utilizado por el SUT Stubs Alimentan al SUT con entradas indirectas esperadas Permiten verificar salidas indirectas del SUT Dummies Objetos sin implementación que se pasan como parámetros de métodos del SUT

19 Frameworks NMock2 TypeMock Rhino Mocks

20 Al verificar los resultados Reducir duplicación de código de verificación Revelar la intención de la prueba Evitar la lógica condicional en los tests («ifs» y «loops»)

21 Integración continua Todo el equipo debe trabajar con la versión más reciente Permite detectar problemas de compatibilidad de manera temprana Reduce los riesgos y tiempos de integración Cada desarrollador es responsable de integrar su propio código

22 Code coverage Métrica del grado en que el código de un software es testeado Criterios de coverage Función Sentencia Decisión Condición (true/false) Condición / Decisión

23 Bibliografía xunit Test Patterns: Refactoring Test Code (Gerard Meszaros) Integración Continua (Martin Fowler)

24 FIN