TDD 101 - Introducción al Desarrollo Dirigido por Pruebas

TDD - 101
Orlando Bustos Mateluna - 2017

Agenda
Tipos de Test
Definición / Flujos
¿Por Qué?
Beneficios / Costos
Principios
Ejemplo
Desafíos / Experiencias

Tipos de Test
Funcional
Unitarios
Mutación
Integración
Aceptación

Tipos de Test - Unitarios
• Prueba Unitaria
– Una prueba unitaria es una
forma de comprobar el
correcto funcionamiento de
una unidad de código.
• función
• procedimiento
• clase

Flujo Tradicional
Diseño
Test
Código
TRADICIONAL

TDD - Definición
• TDD son las siglas de Test Driven
Development, desarrollo dirigido por
pruebas.
• Proceso de desarrollo de software que se
basa en la idea de desarrollar pruebas,
codificar y refactorizar el código
construido.

T
D
D
F
l
u
j
o
Escribir un test
¿Pasó?
Escribir código Correr el test
¿Pasó?
Remover Errores
Refactorizar
Correr el test
¿Pasó?
Si
Si
Si
No
No
NoCorrer el test

TDD - ¿Por qué antes?
● De la manera tradicional las
pruebas suelen
estar condicionadas a lo
implementado, con lo que es
fácil obviar pruebas o olvidar
algunos casos de test.

• Al realizar primero las pruebas se realiza
un ejercicio previo de análisis, de los requisitos y
de los diversos escenarios.

– En mi experiencia, es fome, fome, fomisimo, hacer las pruebas
después de terminar el código.
– Como es tan aburrido, se hacen las pruebas mínimas para
poder escapar rápido de esa tarea.

TDD - ¿Por qué?
• TDD ayuda a producir diseños más simples y
menos acoplados.

TDD - ¿Por qué?
• TDD ayuda a crear un gran conjunto de pruebas
que dan "confianza" para realizar cambios o
incrementar la funcionalidad del sistema.

TDD - Costos
• Curva de aprendizaje pronunciada.
• El testing ralentiza el prototipado rápido.
• Los primeros sprints se suele entregar menos de
lo normal.

TDD - Beneficios
• Mejor cobertura de Test
• Mejor Diseño
• Solo funcionalidad requerida
• Ayuda a manejar el miedo de
cara a la complejidad
• Documentación de código
• Aumenta la calidad general

TDD - Beneficios
• Evidencia concreta de que tu
codigo funciona
• Acorta el tiempo de feedback
• Defectos después de deployar
son muy raros y poco críticos.

TDD - Principios (Reglas) - RED
No está permitido escribir código productivo sin tener una
prueba que falle.

TDD - Principios (Reglas) - RED
No está permitido escribir más código en una prueba, que el
necesario para que falle la misma.

TDD - Principios (Reglas) - GREEN
No está permitido escribir más código
productivo que el necesario para pasar su
prueba unitaria.
Babysteps.
Siguiendo patrones y buenas
prácticas.

TDD - Principios (Reglas) - REFACTOR
Eliminar duplicaciones y otros “code smells”.
– Hediondeces del código.

TDD - Code Smells
• Hediondeces de código comunes:
– Código duplicado
– Método grande
– Clase grande
– Demasiados parámetros
– Envidia de características
– Excesivo uso de literales

TDD - Desafíos
● Las pruebas se tornan difíciles de escribir
○ por lo que sentimos una desaceleración importante.

TDD - Desafíos
● Son frágiles
○ por lo que cambios aparentemente sin importancia en el código
provocan que un montón de pruebas fallen.

TDD - Desafíos
● Mantenerlas en forma y funcionando se vuelve complejo y
consume tiempo.

TDD - Desafíos
● Finalmente nos damos por vencido y abandonamos
completamente nuestras mejores intenciones y pensamos
“Simplemente no vale la pena”.

TDD - Experiencias anteriores
• Copy-Paste
– Cuando se “copipastea” se tiende a olvidar TDD.

• Fragilidad
– Cualquier cambio en el código afecta las pruebas.

• Cobertura
– Desde el 1er
Commit tienes mínimo 80%.

TDD - Conclusión
• No es una bala de plata
“No existirá [en el horizonte de una década] un avance en tecnología o gestión, que por sí solo pueda
provocar una mejora en la productividad, fiabilidad y simplicidad en un orden de magnitud
[significativo/por diez] - Fred Brooks”

TDD - Conclusión
• Beneficios Comprobados
– (2008) - “TDD teams produced code that was 60 to
percent better in terms of defect density than non-T
teams.”

TDD - Conclusión
• Cambia la manera de pensar y trabajar
– Es complejo imaginar algunas pruebas a priori.

TDD - Conclusión
• Disciplina y Constancia
– Se requiere ser disciplinado y constante para no
abandonar en el peor momento de la curva de adopción.

TDD - Referencias
• Test driven development overview and adoption
– http://www.slideshare.net/pyxistech/test-driven-develop
ment-overview-and-adoption
• Comparative Study of Test Driven Development
with Traditional Techniques
– http://www.ijsce.org/attachments/File/v3i1/A1351033113
.pdf

TDD - Referencias
• TDD cómo y por qué, una guía para los no
iniciados
– http://artesanos.de/software/2012/02/13/tdd-como-y-po
rque-una-guia-para-los-no-iniciados/
• Introducción a TDD (Test Driven Development)
– http://blog.lordudun.es/2011/04/introduccion-a-tdd-test-
driven-development/

TDD - Referencias
• Conventional TDD is Sin!!
– http://agile.dzone.com/news/conventional-tdd-si
n
• 7th ANNUAL STATE of AGILE VERSIONONE®
Agile Made Easier DEVELOPMENT SURVEY
– http://www.versionone.com/pdf/7th-Annual-Stat
e-of-Agile-Development-Survey.pdf

TDD - Referencias
• Hediondez del Código
– http://es.wikipedia.org/wiki/Hediondez_del_c%C3%B3dig
o
• https://ryoshiga.com/category/tdd/
• https://www.slideshare.net/AtishNarlawar/td
d-in-agile

TDD - Referencias
• https://www.microsoft.com/en-us/research/blog/
exploding-software-engineering-myths/

TDD 101 - Introducción al Desarrollo Dirigido por Pruebas

Más contenido relacionado

La actualidad más candente (20)

Similar a TDD 101 - Introducción al Desarrollo Dirigido por Pruebas (20)

Último (11)

TDD 101 - Introducción al Desarrollo Dirigido por Pruebas