Presentación en la que se argumenta que la metodología TDD es ortogonal al uso de lenguajes con tipado estático o dinámico.

1. Testing, tipos y otros
flamewars
Francisco Ros
Murcia DevOps
Septiembre 2017

2. Testing · Tipado = 0
Realizar testing y utilizar lenguajes de tipado
estático o dinámico son asuntos completamente
ortogonales
¿Debo escribir tests? Altamente recomendable
¿Tipado estático o dinámico? Choose the right tool
for the job
Flamewar
Ahead

3. ¿Pero haces testing?
TDD para desarrollar Moss
CI/CD pipeline para todo componente
900 tests en micro-servicios PythonFrancisco Ros
CEO & Dev @ Doalitic
Ahora: Python
Antes: C/C++, Java, Perl

4. Automatic sysadmin for web
development teams
CLOUD VPS AMAZON
DIGITALOCEAN GOOGLE VULTR
ZERO-CONFIG MONITORING
ALERTS SLACK HTML/CSS/JS
PHP LARAVEL SYMFONY
WORDPRESS ZERO-DOWNTIME
DEPLOYMENTS GITHUB
BITBUCKET HEALTH-CHECKS
https://moss.sh

5. Nuestro pipeline para un
micro-servicio Python
Documentación
PEP8 + complejidad ciclomática
Test “unitarios”
Test de componente / integración

6. 1. Intro
Un poco de contexto...
➔ ¿Por qué hacer tests?
Calidad, agilidad, regresiones.
➔ Testing
Tipos.
➔ TDD
Metodología ágil de desarrollo de
software.
➔ La polémica
¡Flame!

7. Escribimos tests para detectar y
solucionar bugs cuanto antes.
Los tests prueban que el software
se comporta de acuerdo a su
especificación.
Los tests detectan regresiones
conforme el software evoluciona.
En definitiva, una buena suite de
tests mejora la calidad (grado de
confianza) del software.
Agile
En buena medida, todas
las metodologías ágiles
tienen su razón de ser
en lo que se desprende
de este gráfico.

8. Tipos de tests
Manual vs Automático
Unitario vs Componente vs
Integración vs Sistema vs ...
Funcional vs No funcional
Caja negra (estado, clásico)
Caja blanca (comportamiento, mockist)
Etc
Unitariospermiten medir
cobertura de código
La pirámide
Fuente:
Behavior Driven Testing in
Agile

9. Test
Driven
Development
Fuente:
Agile Nutshell
Es una METODOLOGÍA ágil de
desarrollo de software
TDD ⇒ Testing
Testing ⇏ TDD
TDD ≠ Testing
Recursos:
Blog de Martin Fowler

10. El origen
You don’t need static type checking if you
have 100% unit test coverage
http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.ht
ml
Imagen:
http://saltares.com/blog/computing/book-review-clean-cod
e/

11. La reacción
http://typeinference.com/scala/2016/05/03/tdd-vs-static-typing.html
http://naildrivin5.com/blog/2016/05/03/type-wars-are-far-from-over.html
https://www.reddit.com/r/programming/comments/4h9p95/clean_coder_blog_type_wa
rs/
https://news.ycombinator.com/item?id=1771595

12. 2. Mitos
Algunos mitos sobre testing y lenguajes con
tipado dinámico:
➔ Necesitas hacer más tests
➔ Necesitas más cobertura
➔ Necesitas refactorizar a mano

13. “Hay que comprobar los
argumentos de todas la
funciones porque te puede
llegar cualquier cosa”

14. No → sobre-especificación
No → cliente incumple contrato

15. “hacer tests unitarios estúpidos que no
son necesarios porque el compilador ya
te asegura que no va a pasar nada… esos
tests no tienen sentido, pero los tienes
que hacer igualmente en lenguajes con
tipado dinámico”

16. Yeah, se comporta como debe
Si fueran tipos estáticos,
¿acaso haría menos tests?
Siendo tipos dinámicos,
¿hay más tests obligatorios?

18. 1. No hay diferencia respecto a un
lenguaje con tipado estático
2. 100% cobertura no es obligatoria,
es más importante la calidad de los
tests
3. Veremos cómo ampliar esa
cobertura al 100%
Ok, pero no estás
comprobando casos de
error. Tienes que escribir
más tests o no tendrás
100% de cobertura.

19. “I know. You don’t need such test cases. Because there
are other tests that require these attributes and
functions and they will fail if they are missing. But what
if you are not Uncle Bob and you didn’t write these
other test cases? Everything seems to work well in
spite of this part of the code is not tested. And then it
comes a refactor. Some attributes and some functions
are removed or renamed and then… Boom!
AttributeError, NoMethodError and friends in
production! Face it. You have seen this many times.”

21. No hace falta ser Uncle Bob
para escribir estos tests...
¿no los harías en un lenguaje con tipado estático?

22. Validar la entrada es muy
recomendable
Establecer restricciones
es sencillo aunque no
estén soportadas en el
sistema de tipos del
lenguaje

23. “Hay invariantes que hoy en día, y con el
sistema de tipos adecuado se pueden
codificar en el tipo, por lo que
necesitarás menos tests”

24. Estos invariantes son
restricciones que incorporas al
código, pero no garantizan que
el código cumple su
especificación
para evitar test introduces una restricción que
llevada al extremo...
...código más complejo y propenso error
...más regresiones
...test para comprobar que el código es correcto (!!)
...desarrollo más lento

25. No hace falta ser Uncle Bob
para escribir estos tests...
¿no los harías en un lenguaje con tipado estático + invariantes?

26. “Face it. Every time you had to do big refactors in a
dynamically-typed language you felt as a bomb squad
officer. Changing a class is the closer you will get to
“cutting the red or the blue wire” dilemma. And not
only because most of the changes must be done by
hand without the assistance of any tool. Guess what?
You are not Uncle Bob, and you will find parts of your
code without test coverage. Any change on any line of
code may lead to a dirty runtime exception in
production.”

27. Refactorizando
con PyCharm
☺

28. Puedes tener tests no
automáticos
Si no haces CD a producción
tendrás tests exploratorios
en staging
Llevar un bug a producción
alguna vez es inevitable
A mayor cobertura con tests
de calidad, menor será la
probabilidad
Pero si ocurre, usa TDD para
que no vuelva a pasar
Tip
Sé ágil, aplica el sentido
común, aprende de cada
experiencia y evoluciona las
prácticas que mejor se
adaptan a tu equipo y
proyecto.

29. La redención
No, types are not tests. Type systems are not tests. Type
checking is not testing.
Does every step down The Dark Path mean that you can
ignore a certain number of unit tests? Does programming
in Dark Path languages mean that you don’t have to test as
much?
No. A thousand times: NO. Type models do not specify
behavior. The correctness of your type model has no
bearing on the correctness of the behavior you have
specified.
http://blog.cleancoder.com/uncle-bob/2017/01/13/TypesAndTests.ht
ml

30. 3. Contracorriente
Hay quien aboga por eliminar completamente
tests y documentación
➔ #NoTests
➔ #NoDocs
https://thenewstack.io/no-testing-no-documentation-no-problem/

31. 4. ¿Qué elegir?
Criterios a la hora de elegir lenguaje
➔ The right tool for the job

32. Matching entre proyecto y
lenguaje
Matching entre proyecto y
ecosistema
Destrezas de tu equipo
Comunidad / soporte
Expectativas de
crecimiento de tu equipo

33. Conclusión
Testing debería ser obligatorio
TDD es muy recomendable
Los tests no deberían ser un arma
arrojadiza en el flame ‘tipado estático
vs dinámico’