Successfully reported this slideshow.

Kata tdd

0

Share

Upcoming SlideShare
Swift testing ftw
Swift testing ftw
Loading in …3
×
1 of 21
1 of 21

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

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!

×