Parece que cada día más y más gente habla acerca de la artesanía de software. Sin embargo, ¿te haz preguntado porqué prácticamente todos los lideres de este movimiento y la gente "cool" usan y recomiendan usar TDD?, ¿Cual es la conexión entre las pruebas unitarias y la artesanía de software?, ¿Porqué cada aspirante a Artesano debería estar usando TDD? Algunas personas lo han intentado un par de veces y han terminado dándose por vencidos. En esta charla, abordaremos algunas de las dificultades para hacer el "switch" y hacer que TDD trabaje para nosotros, en lugar de luchar a cada paso del camino. Algunas personas lo han intentado un par de veces y han terminado dándose por vencidos. En esta charla, abordaremos algunas de las dificultades para hacer el "switch" y hacer que TDD trabaje para nosotros, en lugar de luchar a cada paso del camino.

1. Artesanía
de
So-ware
y
Desarrollo
Dirigido
por
Pruebas

2. ¿QUÉ
ES
LA
ARTESANÍA
DE
SOFTWARE

3. Manifiesto
por
la
Artesanía
de
So-ware
Como
aspirantes
a
artesanos
de
so-ware,
estamos
elevando
el
nivel
de
desarrollo
de
so-ware
profesional
pracBcándolo
y
ayudando
a
otros
a
aprenderlo.
A
través
de
este
trabajo
hemos
llegado
a
valorar:
• No
sólo
so-ware
que
funciona,
• sino
también
el
so-ware
bien
diseñado
• No
sólo
responder
al
cambio,
• pero
también
agregar
valor
de
forma
sostenida
• No
sólo
los
individuos
y
las
• sino
también
una
comunidad
de
interacciones,
profesionales
• No
sólo
la
colaboración
con
los
• sino
también
de
asociaciones
clientes,
producBvas
Es
decir,
en
la
búsqueda
de
los
elementos
de
la
izquierda
hemos
encontrado
que
los
elementos
de
la
derecha
son
indispensables.

4. ¿Qué
es
la
Artesanía
de
So-ware?
• Es
acerca
de
crear
conciencia
de
lo
que
está
mal
con
el
actual
estado
de
la
prácBca.
• Es
acerca
de
hacer
el
mejor
trabajo
posible.
• Comprometerse
con
nuestra
profesión.
• SenBr
orgullo
del
trabajo
bien
hecho.
• Mejorar
conBnuamente
nuestras
habilidades.
• SaBsfacer
a
nuestros
usuarios
con
so-ware
de
calidad.

5. Lo
que
la
Artesanía
de
So-ware
NO
es
Ingeniería
de
So-ware:
“La
promesa
implícita
de
la
ingeniería
de
so-ware
es
que
si
Benes
un
proceso
sistemáBco
y
cuanBficado,
cualquiera
puede
desarrollar
so-ware
exitosamente.”
-­‐Pete
McBreen

6. Lo
que
la
Artesanía
de
So-ware
NO
ES
• No
es
solo
acerca
de
“Código
Bonito”.
• Darle
la
espalda
a
los
aspectos
de
negocio
y
concentrarse
SOLO
en
el
lado
técnico.
• Buscar
salidas
fáciles,
“aceite
de
víbora”
o
“balas
de
plata”.
• Crear
cerBficaciones
arBficiales
y
un
modelo
de
negocio
a
su
alrededor.

7. DESARROLLO
DIRIGIDO
POR
PRUEBAS
(TDD)

8. Qué
es
TDD
“Test-­‐first
coding
is
not
a
tesBng
technique”
Ward
Cunningham

9. ¿Qué
es
TDD?
(cont.)
• Es
tomar
la
responsabilidad
de
la
calidad
de
nuestro
código.
• Es
entender
el
código
que
escribimos
en
todo
momento,
no
solo
“suponer”
que
entendemos.
• Es
una
habilidad
y
como
tal,
requiere
prácBca
para
dominarse.
• Es
una
disciplina.

10. El
valor
de
TDD

11. Tres
Reglas
(según
Robert
C.
MarBn)
• No
se
permite
escribir
ningún
código
de
producción
sin
tener
una
prueba
que
falle.
• No
se
permite
escribir
más
de
la
prueba
que
lo
necesario
para
fallar
(y
no
compilar
es
fallar).
• No
está
permiBdo
escribir
más
código
de
producción
que
el
necesario
para
pasar
la
prueba
unitaria
ACTUAL.

12. Paso
a
paso…
from unittest import main, TestCase
class TestPrimeFactors(TestCase):
def testPrimesOf0(self):
self.assertEquals([], factorsOf[0])
if __name__ == '__main__':
main()
E
======================================================================
ERROR: testPrimesOf0 (__main__.TestPrimeFactors)
----------------------------------------------------------------------
NameError: global name 'factorsOf' is not defined
----------------------------------------------------------------------
Ran 1 test in 0.001s
FAILED (errors=1)

13. Paso
a
paso…
...
def factorsOf(n):
return []
...
.
----------------------------------------------------------------------
Ran 1 test in 0.000s
OK

14. Paso
a
paso…
...
def testPrimesOf0to1(self):
self.assertEquals([], factorsOf(0))
self.assertEquals([], factorsOf(1))
...
.
----------------------------------------------------------------------
Ran 1 test in 0.000s
OK

15. Paso
a
paso…
...
def testPrimesOf2(self):
self.assertEquals([2], factorsOf(2))
...
.F
======================================================================
FAIL: testPrimesOf2 (__main__.TestPrimeFactors)
----------------------------------------------------------------------
AssertionError: Lists differ: [2] != []
----------------------------------------------------------------------
Ran 2 tests in 0.029s
FAILED (failures=1)

16. Paso
a
paso…
...
def factorsOf(n):
if n > 1:
return [n]
return []
...
..
----------------------------------------------------------------------
Ran 2 test in 0.000s
OK

17. Paso
a
paso…
...
def testPrimesOf2to3(self):
self.assertEquals([2], factorsOf(2))
self.assertEquals([3], factorsOf(3))
...
..
----------------------------------------------------------------------
Ran 2 test in 0.000s
OK

18. Paso
a
paso…
...
def testPrimesOf2to4(self):
self.assertEquals([2], factorsOf(2))
self.assertEquals([3], factorsOf(3))
self.assertEquals([2,2], factorsOf(4))
...
.F
======================================================================
FAIL: testPrimesOf2to4 (__main__.TestPrimeFactors)
----------------------------------------------------------------------
AssertionError: Lists differ: [2, 2] != [4]
----------------------------------------------------------------------
Ran 2 tests in 0.001s
FAILED (failures=1)

19. Paso
a
paso…
...
def factorsOf(n):
result, factor = [], 2
if n > 1:
while n > 1:
return [n]
while n % factor == 0:
result.append(factor)
n /= factor
factor += 1
return []
return result
...
..
----------------------------------------------------------------------
Ran 2 test in 0.000s
OK

20. Aprendiendo
TDD:
Trampas
• Las
pruebas
se
tornan
di_ciles
de
escribir,
por
lo
que
senBmos
una
desaceleración
importante.
• Corren
lentamente,
lo
que
nos
volvemos
renuentes
a
ejecutarlas
frecuentemente.
• Son
frágiles,
por
lo
que
cambios
aparentemente
sin
importancia
en
el
código
provocan
que
un
montón
de
pruebas
fallen.
• Mantenerlas
en
forma
y
funcionando
se
vuelve
complejo
y
consume
Bempo.

21. Escribiendo
pruebas
unitarias
efecBvas
“Las
pruebas
unitarias
deben
ser
legibles,
confiables
y
fáciles
de
mantener”
-­‐Roy
Osherove
“The
Art
of
Unit
TesBng”

22. Escribiendo
pruebas
unitarias
efecBvas:
Legibilidad
• Mis
pruebas
son
tan
importantes
como
el
código
de
producción.
• Aspirar
a
que
mis
pruebas
se
lean
como
una
“receta
de
cocina”
(patrón
composed
method).
• Si
no
es
posible
determinar
lo
que
una
prueba
está
haciendo,
es
probable
que
en
realidad
esté
verificando
múlBples
cosas.

23. Escribiendo
pruebas
unitarias
efecBvas:
Confiabilidad
• Evita
a
toda
cosa
colocar
lógica
en
el
código
de
una
prueba
(if-­‐then,
switch/case,
etc).
• Evita
calcular
el
valor
esperado
DENTRO
de
la
prueba.
• Evita
comparBr
estado
entre
pruebas.
• Usa
inyección
de
dependencias.

24. Escribiendo
pruebas
unitarias
efecBvas:
Mantenibilidad
• Mantén
simple
el
código
de
inicialización.
• Crea
fixtures
o
incluso
casos
de
prueba
especializados
para
cada
escenario.
• Si
es
necesario,
convierte
cada
escenario
en
una
clase
de
prueba
individual.
• Si
una
parte
del
código
es
parBcularmente
di_cil
de
probar,
busca
problemas
en
el
diseño
del
mismo.

25. Escribiendo
pruebas
unitarias
efecBvas:
Rapidez
• Una
prueba
unitaria
efecBva
debería
ejecutarse
en
milisegundos,
NO
EN
SEGUNDOS.
• Si
las
pruebas
no
son
rápidas,
NO
SE
USARÁN.
• Mantén
conjuntos
pequeños
y
bien
enfocados
de
pruebas,
además
de
la
suite
global.

26. Aprendiendo
TDD
(revisado)
• Comienza
con
algo
sencillo
(¡pero
no
te
detengas
ahí!)
• Escribe
muchas
pruebas
(tantas
como
puedas).
• Familiarízate
con
el
ritmo
y
las
reglas
de
TDD.
• Cuando
encuentres
algo
que
no
sabes
como
probar,
apóyate
en
un
compañero.
• Nunca
dejes
de
aprender.

27. Bibliogra_a
• “The
Clean
Coder”
de
Robert
C.
MarBn.
• “Test
Driven
Development:
By
Example”
de
Kent
Beck.
• “The
Art
of
Unit
Tes@ng”
de
Roy
Osherove.
• “Growing
Object-­‐Oriented
SoIware,
Guided
by
Tests”
de
Steve
Freeman
y
Nat
Pryce.
• “Agile
Java:
CraIing
Code
with
Test-­‐Driven
Development”
de
Jeff
Langr.
• “Diseño
Ágil
con
TDD”
de
Carlos
Ble
Jurado
-­‐>
!Es
graBs!
hjp://www.dirigidoportests.com/el-­‐libro

28. • Twijer:
@alfredochv
• Blog:
hjp://pensamientoobjeBvo.blogspot.mx