Test-Driven Design



Test-Driven Design
    GESTIÓN DE SISTEMAS
      INFORMATIZADOS


         Tiago Bergmann
        Steffen von Sivers
1. Introducción


  • TDD =    TEST DRIVEN DESIGN /
             TEST DRIVEN DEVELOPMENT



                     Diseño /
    Desarrollo guiado por pruebas de software



“hacer algo funcionar ahora y mejorarlo más tarde!”
2. La idea


 • Trasladar los requisitos del final a pruebas

 • Escribir pequeños pedazos de código


 • Aplicar pruebas al código


 • Diseño y mejoramiento del código a base de las pruebas




Diseñar           Implementar               Comprobar       Comprobar
3. Procedimiento

                              TDD
        PRUEBAS                              REFACTORIZACIÓN



• Pruebas unitarias                       • Código funciona

 Aplicadas a modulos                     • Proceso de diseño

                                          • Alteración interna
• Test First Development
                                          • no cambios de
 Código todavía no                         comportamiento
  existe
 Código no funciona
3. Procedimiento


                      Escribir prueba




                      Aplicar prueba

                 Prueba falla?
                                    Mejorar diseño?
Mejorar código
                 Si              No              Si   Refactorización
                                        No
                        Comportamiento esperado?
                                No        Si
4. Ventajas

• Fácil encontrar los errores

     Pasos muy pequeños

     comprobados inmediatamente y continuamente
4. Ventajas

• Descubrimiento de errores muy temprano

    Ahorro de tiempo y costes
              Relación de costes para depurar código
       1200
       1000
        800
        600
        400
        200
          0
4. Ventajas

• No código innecesario

     Pruebas no se integran, pero no desperdicio


• Los códigos más confiables

• Fácil cambiar (más tarde) -> aprovechar pruebas antiguas
5. Desventajas

• Pruebas aplicadas incorrectamente/insuficientemente

     Entender importancia de las pruebas

     Software no funciona en mundo real

• Pruebas no detectan todos los errores posibles

• TDD puede aumentar el tiempo de desarrollo y los costos
  (en algunos casos)
GRACIAS

TDD

  • 1.
    Test-Driven Design Test-Driven Design GESTIÓN DE SISTEMAS INFORMATIZADOS Tiago Bergmann Steffen von Sivers
  • 2.
    1. Introducción • TDD = TEST DRIVEN DESIGN / TEST DRIVEN DEVELOPMENT Diseño / Desarrollo guiado por pruebas de software “hacer algo funcionar ahora y mejorarlo más tarde!”
  • 3.
    2. La idea • Trasladar los requisitos del final a pruebas • Escribir pequeños pedazos de código • Aplicar pruebas al código • Diseño y mejoramiento del código a base de las pruebas Diseñar Implementar Comprobar Comprobar
  • 4.
    3. Procedimiento TDD PRUEBAS REFACTORIZACIÓN • Pruebas unitarias • Código funciona  Aplicadas a modulos • Proceso de diseño • Alteración interna • Test First Development • no cambios de  Código todavía no comportamiento existe  Código no funciona
  • 5.
    3. Procedimiento Escribir prueba Aplicar prueba Prueba falla? Mejorar diseño? Mejorar código Si No Si Refactorización No Comportamiento esperado? No Si
  • 6.
    4. Ventajas • Fácilencontrar los errores  Pasos muy pequeños  comprobados inmediatamente y continuamente
  • 7.
    4. Ventajas • Descubrimientode errores muy temprano  Ahorro de tiempo y costes Relación de costes para depurar código 1200 1000 800 600 400 200 0
  • 8.
    4. Ventajas • Nocódigo innecesario  Pruebas no se integran, pero no desperdicio • Los códigos más confiables • Fácil cambiar (más tarde) -> aprovechar pruebas antiguas
  • 9.
    5. Desventajas • Pruebasaplicadas incorrectamente/insuficientemente  Entender importancia de las pruebas  Software no funciona en mundo real • Pruebas no detectan todos los errores posibles • TDD puede aumentar el tiempo de desarrollo y los costos (en algunos casos)
  • 10.