1 of 19

TEST-DRIVEN DEVELOPMENT (TDD)

INGENIERÍA DE SOFTWARE I. FIUBA.

2 of 19

¿QUÉ ES TDD?

  • Es una técnica de desarrollo
  • Iterativo e incremental
  • Feedback inmediato
  • Proceso de aprendizaje
  • Análisis + Diseño + Programación + Testing

​

3 of 19

1 Escribir un test que falle

2 Lograr que todos los tests pasen

3 ¿Se puede mejorar? Refactorizar

3 pasos

¿CÓMO HACER TDD?

  • El más sencillo que se nos ocurra
  • Debe fallar al ejecutarlo

​

  • Implementación más simple posible
  • No abarcar demás

​

​

  • Deben seguir pasando los tests

​

​

4 of 19

1 Escribir un test que falle

2 Lograr que todos los tests pasen

3 ¿Se puede mejorar? Refactorizar

3 pasos

¿CÓMO HACER TDD?

  • El más sencillo que se nos ocurra
  • Debe fallar al ejecutarlo

​

  • Implementación más simple posible
  • No abarcar demás

​

​

  • Deben seguir pasando los tests

​

​

¿Por qué?

5 of 19

1 Escribir un test que falle

2 Lograr que todos los tests pasen

3 ¿Se puede mejorar? Refactorizar

3 pasos

¿CÓMO HACER TDD?

  • El más sencillo que se nos ocurra
  • Debe fallar al ejecutarlo

​

  • Implementación más simple posible
  • No abarcar demás

​

​

  • Deben seguir pasando los tests

​

​

¿Por qué?

6 of 19

1 Escribir un test que falle

2 Lograr que todos los tests pasen

3 ¿Se puede mejorar? Refactorizar

3 pasos

¿CÓMO HACER TDD?

  • El más sencillo que se nos ocurra
  • Debe fallar al ejecutarlo

​

  • Implementación más simple posible
  • No abarcar demás

​

​

  • Deben seguir pasando los tests

​

​

¿Por qué?

7 of 19

1 Escribir un test que falle

2 Lograr que todos los tests pasen

3 ¿Se puede mejorar? Refactorizar

3 pasos

¿CÓMO HACER TDD?

  • El más sencillo que se nos ocurra
  • Debe fallar al ejecutarlo

​

  • Implementación más simple posible
  • No abarcar demás

​

​

  • Deben seguir pasando los tests

​

​

¿Por qué?

8 of 19

Setup

Exercise

Assert

3 partes

ESTRUCTURA DE UN TEST

Definir el contexto / escenario inicial. Pre-condición

​

Ejercitar la funcionalidad que queremos testear

​

​

​

​

​

Verificar que sucede lo esperado. Post-condición

9 of 19

Ejemplo

10 of 19

ROT13

11 of 19

12 of 19

Conclusiones

13 of 19

CONSIDERACIONES

  • Escribir asserts primero ayuda
  • Asertar por casos negativos también!
  • Un test por cada caso
  • Recordar Caso de prueba vs Dato de prueba
  • Baby steps!
  • Perderse por ir rápido, es más lento...

14 of 19

BENEFICIOS

  • Pensar en el uso del sistema
  • Seguridad ante el cambio
  • Historia de lo aprendido
  • Disciplina
  • Feedback inmediato
  • Dividir y conquistar
  • Evitar “análisis-parálisis”
  • Ver que las cosas funcionen = fuerte efecto psicológico!
  • ​

​

15 of 19

Extras

16 of 19

TDD GUIDED BY ZOMBIES

  • Z – Zero
  • O – One
  • M – Many (or More complex)
  • B – Boundaries
  • I – Interface
  • E – Exceptional
  • S – Simple Scenarios, Simple Solutions

17 of 19

TEST FUNCIONALES VS TEST UNITARIOS

  • Testear el QUE y no el CÓMO
  • Cambian mis tests cuando cambia la realidad (el QUE)
  • Mantenibilidad / fragilidad de los tests

18 of 19

TDDGuru

  • https://github.com/mdinota/TDDGuru
  • Arrastrar e instalar el paquete TDDGuru.pck.st
  • Open -> TDDGuru -> Elegir el primer cambio desde donde empezaron a trabajar
    • W amarilla -> Escribiendo test (paso 1)
    • R roja -> Test fallan (paso 2)
    • G verde -> Test pasan (paso 2)
    • R azul -> Refactor (paso 3)
    • Letra verde = OK
    • Letra roja = No respeté el ciclo de TDD

19 of 19

¿DUDAS? ¿PREGUNTAS