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!
Próxima SlideShare
Cargando en…5
×

Kata tdd

376 visualizaciones

Publicado el

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

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
376
En SlideShare
0
De insertados
0
Número de insertados
1
Acciones
Compartido
0
Descargas
2
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

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!

×