Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Kata TDD
Jorge D. Ortiz Fuentes
@jdortiz
Parte 1:
Pruebas del modelo
Aviso para navegantes
★Esto no es una clase, sino
una experiencia compartida.
★Si compartes, aprendemos
todos.
★Si algo no...
¿TDD?
★Test Driven Development
★Es una forma de escribir
software
★Supone pensar primero en la
verificación del código y
l...
¿Por qué TDD?
★Codigo que hace lo que
pensamos.
★Programar en piloto
automático.
★Progreso medible.
★Mucho más fácil abord...
Secuencia de trabajo
★Siguiente funcionalidad
★Escribir la prueba
★Escribir el código más simple
que pasa la prueba
★Refac...
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
...
Las herramientas
★Introspección (OCUnit)
★Inyección de dependencias
๏Constructor
๏Propiedades
★Mocks y stubs
8
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 ca...
Algunos trucos
★Usar sut = reutilizar pruebas
★Confirmar que no hay avisos o
errores
★Separar en clases
★Refactorizar las ...
Inconvenientes
★ Más lento y más trabajo en calidad
★ Diseño sin visión de conjunto
★ Reescribir pruebas al cambiar
requis...
Ventajas
★ Menos interactuación y menos
tiempo depurando
★ Más facil adaptarse a los cambios
★ Documentación en código y m...
Parte 2:
Pruebas de VC
Interfaz de la app
★Maestro/detalle
๏Maestro: Mezclas agrupadas por
categorías
๏Detalle: Mezcla y sus datos
14
View ctlr maestro
★BlendsViewController
★Lista (subclase de
UITableViewController)
15
View ctrlr detalle
★BlendDetailsViewController
★Subclase de UIViewController
16
A tener en cuenta
★Problemas con OCMock de Core
Data (NSProxy)
★No todos los métodos están
pensados para ser probados
(KVC...
Parte 3:
Código de otros
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.Refacto...
Código limpio
★Aprovechar para limpiar el
código
★Eliminar repetición y ganar
consistencia
★Sólo un nivel de abstracción
p...
¡Gracias!
Upcoming SlideShare
Loading in …5
×

Kata tdd

417 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Kata tdd

  1. 1. Kata TDD Jorge D. Ortiz Fuentes @jdortiz
  2. 2. Parte 1: Pruebas del modelo
  3. 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. 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. 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. 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. 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. 8. Las herramientas ★Introspección (OCUnit) ★Inyección de dependencias ๏Constructor ๏Propiedades ★Mocks y stubs 8
  9. 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. 10. Algunos trucos ★Usar sut = reutilizar pruebas ★Confirmar que no hay avisos o errores ★Separar en clases ★Refactorizar las pruebas cuando interese 10
  11. 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. 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. 13. Parte 2: Pruebas de VC
  14. 14. Interfaz de la app ★Maestro/detalle ๏Maestro: Mezclas agrupadas por categorías ๏Detalle: Mezcla y sus datos 14
  15. 15. View ctlr maestro ★BlendsViewController ★Lista (subclase de UITableViewController) 15
  16. 16. View ctrlr detalle ★BlendDetailsViewController ★Subclase de UIViewController 16
  17. 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. 18. Parte 3: Código de otros
  19. 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. 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. 21. ¡Gracias!

×