21
Kata TDD Jorge D. Ortiz Fuentes @jdortiz

Kata tdd

Embed Size (px)

DESCRIPTION

Presentación usada para las 3 partes de la Kata llevada a cabo en julio de 2013 en la NSCoders Night.

Citation preview

Page 1: Kata tdd

Kata TDDJorge D. Ortiz Fuentes

@jdortiz

Page 2: Kata tdd

Parte 1:Pruebas del modelo

Page 3: Kata tdd

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

Page 4: Kata tdd

¿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

Page 5: Kata tdd

¿Por qué TDD?★Codigo que hace lo que pensamos.

★Programar en piloto automático.

★Progreso medible.

★Mucho más fácil abordar cambios.

5

Page 6: Kata tdd

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

Page 7: Kata tdd

Código más corto1.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

Page 8: Kata tdd

Las herramientas★Introspección (OCUnit)

★Inyección de dependencias๏Constructor

๏Propiedades

★Mocks y stubs

8

Page 9: Kata tdd

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

Page 10: Kata tdd

Algunos trucos★Usar sut = reutilizar pruebas

★Confirmar que no hay avisos o errores

★Separar en clases

★Refactorizar las pruebas cuando interese

10

Page 11: Kata tdd

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

Page 12: Kata tdd

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

Page 13: Kata tdd

Parte 2:Pruebas de VC

Page 14: Kata tdd

Interfaz de la app★Maestro/detalle๏Maestro: Mezclas agrupadas por

categorías

๏Detalle: Mezcla y sus datos

14

Page 15: Kata tdd

View ctlr maestro★BlendsViewController

★Lista (subclase de UITableViewController)

15

Page 16: Kata tdd

View ctrlr detalle★BlendDetailsViewController

★Subclase de UIViewController

16

Page 17: Kata tdd

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

Page 18: Kata tdd

Parte 3:Código de otros

Page 19: Kata tdd

Modelo de trabajo1.Leer el código2.Pensar una prueba que confirma cómo funciona

3.Escribirla y ver que la pasa4.Refactorizar si procede.5.Repetir

19

Page 20: Kata tdd

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

Page 21: Kata tdd

¡Gracias!