El documento presenta una introducción al desarrollo guiado por pruebas (TDD) en 3 partes. La primera parte explica la secuencia de trabajo de TDD, los beneficios y desafíos. La segunda parte describe las pruebas de la interfaz de usuario de una aplicación de muestras. La tercera parte presenta un método para probar y refactorizar código de otros desarrolladores.

1. Kata TDD
Jorge D. Ortiz Fuentes
@jdortiz

2. Parte 1:
Pruebas del modelo

3. Aviso para navegantes
★Esto no es una clase, sino
una experiencia compartida.
★Si compartes, aprendemos
todos.
★Si algo no te gusta, ofrece
tus alternativas.
3

4. ¿TDD?
★Test Driven Development
★Es una forma de escribir
software
★Supone pensar primero en la
verificación del código y
luego en escribirlo
4

5. ¿Por qué TDD?
★Codigo que hace lo que
pensamos.
★Programar en piloto
automático.
★Progreso medible.
★Mucho más fácil abordar
cambios.
5

6. Secuencia de trabajo
★Siguiente funcionalidad
★Escribir la prueba
★Escribir el código más simple
que pasa la prueba
★Refactorizar
★Repetir hasta acabar cada
historia
6

7. Código más corto
1.Más fijado (hard coded)
2.Más cerca del principio del
método
3.Menos sangrado (indented)
4.Más corto
7
Texto
http://osherove.com/blog/2010/1/6/tdd-4-questions-that-
will-help-you-create-the-simplest-thing.html

8. Las herramientas
★Introspección (OCUnit)
★Inyección de dependencias
๏Constructor
๏Propiedades
★Mocks y stubs
8

9. Las reglas del juego
★Sólo probamos nuestro código
★Sólo un nivel cada vez
★Sólo los métodos públicos
★Sólo una cosa en cada prueba
★Las pruebas son
independientes unas de otras
(ni secuencia, ni estado)
9

10. Algunos trucos
★Usar sut = reutilizar pruebas
★Confirmar que no hay avisos o
errores
★Separar en clases
★Refactorizar las pruebas
cuando interese
10

11. Inconvenientes
★ Más lento y más trabajo en calidad
★ Diseño sin visión de conjunto
★ Reescribir pruebas al cambiar
requisitos
★ Se requieren otras pruebas además
★ Mismas carencias las pruebas que
el código (sistema que no puede
entenderse a sí mismo, W.E.Deming)
11

12. Ventajas
★ Menos interactuación y menos
tiempo depurando
★ Más facil adaptarse a los cambios
★ Documentación en código y menos
asunciones.
★ Cobertura prácticamente total
12

13. Parte 2:
Pruebas de VC

14. Interfaz de la app
★Maestro/detalle
๏Maestro: Mezclas agrupadas por
categorías
๏Detalle: Mezcla y sus datos
14

15. View ctlr maestro
★BlendsViewController
★Lista (subclase de
UITableViewController)
15

16. View ctrlr detalle
★BlendDetailsViewController
★Subclase de UIViewController
16

17. A tener en cuenta
★Problemas con OCMock de Core
Data (NSProxy)
★No todos los métodos están
pensados para ser probados
(KVC al rescate)
17

18. Parte 3:
Código de otros

19. Modelo de trabajo
1.Leer el código
2.Pensar una prueba que
confirma cómo funciona
3.Escribirla y ver que la pasa
4.Refactorizar si procede.
5.Repetir
19

20. Código limpio
★Aprovechar para limpiar el
código
★Eliminar repetición y ganar
consistencia
★Sólo un nivel de abstracción
por método
20

21. ¡Gracias!