Desarrollo de Software conducido por Pruebas

Transcripción

1 Desarrollo de Software conducido por Pruebas Test-Driven Development Aportes de: Agustín Goñi Microsoft Cono Sur

2 Temario Testeo de aplicaciones Desarrollo conducido por las pruebas Impacto en el proceso de desarrollo Herramientas para TDD Buenas prácticas y recomendaciones

3 Desarrollo conducido por pruebas Procesos de desarrollo tradicionales Etapas de análisis, diseño, implementación y testeo claramente separadas. Asumen un diseño correcto al primer intento. Se espera a tener el componente o pieza de software implementado para hacer pruebas. Fallas en la etapa de testing significan tener que rehacer muchas trabajo. Alto costo e impacto.

4 Desarrollo conducido por la prueba Procesos de espiral Se construye por iteración. Las etapas están separadas dentro de cada iteración, pero no en el proyecto completo. Se reduce el riesgo de detectar tardíamente errores de muy alto costo. A pesar de todo es necesario construir antes de comenzar el testing.

5 Inconvenientes y problemas Degradación del diseño Las pruebas se dejan para el final. Los errores pequeños no son detectados a tiempo y se propagan. Los errores del componente se arreglan extraoficialmente. El diseño no corresponde a la realidad; es el código el que manda.

6 Temario Testeo de aplicaciones Desarrollo conducido por las pruebas Impacto en el proceso de desarrollo Herramientas para TDD Buenas prácticas y recomendaciones

7 Desarrollo conducido por la prueba Qué es el desarrollo conducido por la prueba? Una técnica para la construcción de software que consiste en producir pruebas unitarias automáticas antes de escribir el código. Proviene de la filosofía de Extreme Programming, buscando un proceso de desarrollo más ágil.

8 Desarrollo conducido por la prueba Por qué antes? Es una forma de prevenir defectos. Permite analizarlos y contenerlos antes que se introduzcan en el código. Busca detectar los errores antes en vez de arreglarlos después.

9 Desarrollo conducido por la prueba Cómo funciona? Esquema Red/Green/Refactor 1. El desarrollador escribe tests unitarios para el componente que está por construir. 2. Compila (lo cual debería fallar: no se ha implementado) 3. Escribe código sólo para que compile. 4. Corre el test (lo cual debería fallar). 5. Arregla el código para que pase el test. 6. Corre el test y ve que pasa OK. 7. Hace refactoring del código para eliminar la duplicación y hacerlo más legible y mantenible 8. Vuelve a repetir.

10 Desarrollo conducido por la prueba Cómo se realiza la prueba unitaria? Los desarrolladores ejecutan el código para verificar que cumple los requisitos del diseño. Si se encuentran defectos se hace debug. Estas actividades se alternan con la codificación. Muchas veces se agrega código de prueba para ejecutar el componente.

11 Desarrollo conducido por la prueba Código de prueba A veces luego de terminado el desarrollo, se descarta el código de prueba. A veces se guarda, pero mezclado con el código de producción (ej. en un método de prueba). Como la prueba unitaria es responsabilidad del desarrollador, en general no se define un estándar para ordenar el código de prueba.

12 Desarrollo conducido por la prueba Porque es un conductor del desarrollo? El conjunto de prueba define una especificación programática del componente. Hacerlo antes del desarrollo permite tener un criterio de satisfacción de los requisitos de diseño. Es una guía de lo que se debe implementar. Más importante, es un mecanismo que permite al diseño evolucionar. Se postergan las decisiones hasta tener información más completa.

13 Desarrollo conducido por la prueba Proceso simple El desarrollador hace la prueba con las mismas herramientas que usa y en el mismo lenguaje de programación. Ordena prácticas que ya están presentes y ayuda a darle foco a la prueba.

14 Temario Testeo de aplicaciones Desarrollo conducido por las pruebas Impacto en el proceso de desarrollo Herramientas para TDD Buenas prácticas y recomendaciones

15 Impacto en el proceso de desarrollo El desarrollo conducido por la prueba afecta varias áreas del desarrollo: Prevención de defectos. Mantenimiento. Diseño simple. Confianza del desarrollador. Documentación. Trabajo en equipo.

16 Impacto en el proceso de desarrollo Prevención de defectos Es el impacto directo de la técnica. Se produce código con menos defectos, se previenen y corrigen muy temprano. El conjunto de casos de prueba unitaria hace que el software sea auto-verificable.

17 Impacto en el proceso de desarrollo Mantenimiento Repetir las pruebas muchas veces es fácil, agiliza el ciclo de desarrollo y el mantenimiento. Cuando tenemos que realizar un cambio es menos riesgoso romper algo. Contamos con una especificación programática del comportamiento.

18 Impacto en el proceso de desarrollo Diseño simple Guía al desarrollador a un diseño simple. Generalmente un diseño fácil de probar es un buen diseño. Conduce a una interfaz simple y evita el acoplamiento. Al implementar la interfaz se hace lo mínimo necesario para satisfacer el test.

19 Impacto en el proceso de desarrollo Confianza del desarrollador El método incentiva los incrementos pequeños fácilmente verificables. Se puede hacer una modificación y saber inmediatamente si todo sigue funcionando. Refactoring del código con muy poco peligro de romper algo.

20 Impacto en el proceso de desarrollo Documentación Los casos de prueba constituyen una documentación muy completa del comportamiento del componente.

21 Impacto en el proceso de desarrollo Trabajo en equipo Relacionado con las prácticas de XP La facilidad de cambiar la funcionalidad se traslada fácilmente a todos los miembros. Lo importante es que se cumplan las pruebas sin importar quien modifique el componente. No hay propietarios.

22 Temario Testeo de aplicaciones Desarrollo conducido por las pruebas Impacto en el proceso de desarrollo Herramientas para TDD Buenas prácticas y recomendaciones

23 Herramientas para TDD Para poner todo esto en práctica necesitamos una herramienta que permita: Definir tests unitarios. Ejecutarlos de manera automática. Mantenerlos independientes del código de la aplicación. Hacer cambios y volver a correr los tests de manera transparente. Proveer una interfaz de usuario clara e informativa.

24 Herramientas para TDD Se han desarrollado varias opciones: Originalmente el framework XUnit para C/C++ sobre Unix. JUnit para Java basado en ese framework, creado por Erich Gamma y Kent Beck Nunit, MbUnit para.net. Varios otros para lenguajes/ambientes específicos. Algunas herramientas de desarrollo lo están incorporando en la IDE.

25 Herramienta NUnit Definiendo NUnit Cumple con las condiciones que se busca en una herramienta de TDD. Es un conjunto de clases (framework) que se extienden por herencia. Es una herramienta de diseño muy simple. Las pruebas se pueden codificar en cualquier lenguaje.net.

26 Herramienta NUnit Radiografía de un caso de prueba: Estímulo Respuesta Evaluación Ejemplo (C#) [Test] public void PushOne() { stack.push( first element ); Assert.IsFalse(stack.IsEmpty); }

27 Herramienta NUnit Ejecución utilizando TestRunners

28 Herramienta NUnit Atributos en NUnit 2.x A partir de la versión 2 se utilizan atributos. Nos permiten atribuir características al código, en un nivel de abstracción diferente al de la funcionalidad.

29 Herramienta NUnit Ejemplo de atributos en NUnit <Test()> Define un método de prueba <TestFixture()> Define una clase que contiene métodos de prueba <ExpectedException(Excepcion)> Cuando el resultado esperado es una excepción <Ignore( Mensaje )> No se corre la prueba, pero da una alerta amarilla. <SetUp()> Método de inicialización del fixture <TearDown()> Método de finalización

30 Demo NUnit y VisualStudio.NET

31 Definición n de Stack Estructura de datos que almacena información en forma LIFO. Operaciones: Push Pop Top IsEmpty Push Top Pop IsEmpty?

32 Tests para un Stack 1. Crear un Stack y ver que IsEmpty() es true. 2. Push un único elemento y verificar que IsEmpty() es false. 3. Push un único elemento, luego Pop, y verificar que IsEmpty() es true. 4. Push un único objeto, recordándolo, luego Pop y verificar que ambos son iguales. 5. Push tres objetos, recordándolos y luego Pop, uno por uno, verificando su igualdad y orden correcto. 6. Pop un Stack sin elementos. 7. Push un único elemento, usar Top y verificar IsEmpty es false. 8. Push un elemento, recordándolo y luego usar Top y verificar que es el mismo elemento. 9. Llamar a Top con un Stack vacío.

33 Conclusiones How much of the intended code (Stack) is covered by one or more tests? 100% Coverage How much code was implemented in Stack.cs that didn t serve for the required functionality? None (Implement only what is needed) How certain are we that the code works? 100% If we need to change Stack s implementation to use (for example) a linked list, would it be easy to ensure we don t break current version? Yes! If someone new needs to find out what the implemented class is intended to do, how can he/she learn? Read unit tests. They serve as formal documentation. (Therefore, store Unit Tests with the official code)

34 Extensiones de NUnit Existen extensiones de la herramienta, orientados a ciertos modelos de aplicación Estas herramienta facilitan las pruebas específicas, permitiendo un mayor nivel de abstracción. Ejemplo: Win Forms, ASP, XML, etc.

35 Extensiones de NUnit NUnitASP y NUnitForms Periten realizar pruebas funcionales que ejecutan acciones sobre la GUI. Proveen de clases helper para Ubicar controles en el form Analizar el contenido Disparar eventos.

36 Extensiones de NUnit Ejemplo NUnitForms (C#) Form form = new Form(); form.show(); ControlTester button = new ControlTester( nombreboton"); button.fireevent("click"); ControlTester textbox = new ControlTester( nombretxtbox"); textbox[ texto"] = texto"; Assertion.AssertEquals("defaultText", textbox[ texto"];

37 Extensiones de NUnit Ejemplo NUnitASP (C#) LabelTester label = new LabelTester( label", WebForm); LinkButtonTester link = new LinkButtonTester("linkBtn", WebForm); Browser.GetPage(" // Probar objetos de la página link.click(); AssertEquals( un click", label.text);

38 Visual Studio 2005

39 Visual Studio Team System Process and Architecture Guidance Visual Studio Team Architect Application Modeling Logical Infra. Modeling Deployment Modeling Class Modeling Visio and UML Modeling Visual Studio Team Developer Dynamic Code Analyzer Static Code Analyzer Code Profiler Team Foundation Client Visual Studio Professional Edition Unit Testing Code Coverage Visual Studio Team Test Load Testing Manual Testing Test Case Management Visual Studio Industry Partners Visual Studio Team Foundation Change Management Work Item Tracking Reporting Project Site Integration Services Project Management

40 Temario Testeo de aplicaciones Desarrollo conducido por las pruebas Impacto en el proceso de desarrollo Herramientas para TDD Buenas prácticas y recomendaciones

41 Buenas prácticas y recomendaciones Recomendaciones prácticas Pensar en todos los casos de prueba necesarios; abordarlos uno a uno. Mantener los casos de prueba simples No confiar en un orden particular de ejecución No dejar efectos laterales luego de la prueba Si se encuentra un defecto, agregar el caso que lo muestra primero, luego corregir

42 Buenas prácticas y recomendaciones Se puede escribir la prueba después o por un equipo independiente? Lo podría hacer un equipo independiente, pero se pierde el feedback de las pruebas. Se puede codificar la prueba luego de terminado el componente pero no se obtienen los mismos beneficios. No sirve como prevención, ni como análisis del problema.

43 Buenas prácticas y recomendaciones Automatización No intentar automatizar todo el proceso de prueba, puede no ser viable ni práctico. La prueba debe ser estratégica en la búsqueda de defectos. Utilizar distintos niveles y técnicas, los defectos son evasivos.

44 Buenas prácticas y recomendaciones Prueba funcional vs. TDD Se ejecuta el software con el objetivo de encontrar defectos, con la perspectiva del usuario. Prueba el sistema o divisiones funcionales como los casos de uso, a través de la IU. Puede ser costosa de automatizar. La prueba funcional sigue siendo necesaria y es una actividad complementaria al desarrollo conducido por la prueba.

45 Resumen

46 Resumen TDD es una técnica para desarrollar basado en las pruebas. TDD puede mejorar significativamente el proceso de desarrollo. Existen herramientas que permiten llevarlo a cabo en forma automática.

47 Referencias James Newkirk; Test Driven Development in Microsoft.NET Kent Beck; Test Driven Development, by example Will Stott, James Newkirk; Test-Driven C#, Improve the Design and Flexibility of Your Project with Extreme Programming Techniques ng Visual Studio 2005 Team System Herramientas Noticias, recursos