BizTalk Server 2006 & Test Driven Development Kabel Sistemas S.L.

¿Quienes Somos? Compañía especializada en Consultoría de TI ¿Qué hacemos? Infraestructura de redes y sistemas Seguridad Desarrollo Gestión de proyectos y dirección estratégica Formación Aplicada IT OutSourcing La calidad cómo objetivo fundamental de nuestros proyectos Nuestra vocación es convertirnos en el socio tecnológico que toda empresa necesita

Agenda Introducción Pruebas Conceptos TDD (Test Driven Development) TDD en proyectos de integración Demos, demos, demos….

¿Por qué probamos? Para verificar que: hemos terminado cumplimos los requerimientos modificaciones en el código no rompen el ya existente arreglamos los bugs Para mitigar nuestro miedo Para saber que progresamos

Pruebas unitarias Herramienta de desarrollo Escritas por desarrolladores Prueban una funcionalidad concreta y reducida Prueban el comportamiento externo Funcionan o no Repetibles Automatizables Código de producción

Anatomía de una prueba Estructura AAA A Arrange (Fixture) Preparar el contexto de la prueba (datos de prueba, inicializar objetos) A Act: Ejecutar la funcionalidad a probar A Assert: Verificar los resultados frente a lo esperado

Reglas Funcionamiento independiente No asumir el estado del sistema No escribir pruebas que funciona a la primera Comenzar por el caso nulo Pruebas repetibles Promover el bajo acoplamiento Usar mock objects Escribir primero la prueba

Probar antes vs probar después Después: Estructurar el código en nuestra mente o usando documentos de diseño Verificar esta estructura mentalmente Pruebas automatizadas son difíciles de añadir porque el diseño no está pensado para ser probado Las intenciones del código se almacenan separadas Sólo malas noticias Antes: La estructura se contruye programando y se registra en forma de pruebas Todo aspecto de la estructura se comprueba usando la máquina El código está diseñado para ser probado Las pruebas ofrecen ejemplos de las intenciones Rojo Verde Avance!

Test Driven Development Práctica de eXtreme Programming (XP) Forma de pensar en el desarrollo software Las pruebas dirigen el desarrollo Escribir una prueba antes que el código Simplificar el diseño y desacoplar Escribir el código más simple que pueda funcionar Objetivos: Menos errores, menos depuración Más confianza, más productividad Mejor diseño

Test Driven Development Problema Cambios en el código crean defectos Miedo a realizar cambios, diseño deteriorado Un buen diseño OO es difícil a la primera Más tiempo probando que escribiendo código Solución Establecer un proceso que permita: Modificar cambios con confianza Mejorar el diseño incrementalmente

Ritmo TDD (Red - Green - Refactor) 1. Escribir una prueba 2. Escribir el esqueleto del código 3. Compilar 4. Verificar que la prueba falla 5. Escribir el código más sencillo para que la prueba funcione 6. Verificar que la prueba funciona 7. Simplificar el código mediante refactoring 8. Verificar que las pruebas funcionan 9. Volver a 1

TDD en proyectos de integración

Testing Functoids DEMO

Testing Maps DEMO

Testing Pipelines DEMO

Testing Orchestrations DEMO

Más información Kabel Sistemas: Dev Center: Comunity: BizTalkGurus: NewsGroup: MSN Search:

Preguntas && Respuestas ?

© Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

© Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.