TDD 2020

As the tests get more specific, the code gets more generic - Robert C. Martin
Prácticas = Principios(Contexto)

Más cercanos a negocio y no tan ligado a la implementación, en vez 'return string empty when is null', mejor 'allow null'
El nombrado de las pruebas
Refactorizar las pruebas
Intentar evitar las variables global o variables estáticas o singleton, que comparten estado
Que los test sean lo más sencillos posibles, sin bucles o condicionales. En una primera versión el tests puede ser complejo, pero una vez está en verde, podemos mejorarlo

Los tests parametrizado, quitan legibilidad porque estamos usando valores que a priori no tiene semántica y también quitamos los nombres de los tests.
los test no pueden garantizar la ausencia total de fallos en el software ni mucho menos

Fast (rápido) -> como mucho unos cuantos segundos
Independent (independiente) -> no tener dependencias con otras pruebas
Repeatable (repetible) inocuo, no altera el sistema
Self-validated (auto-validado) -> contiene aserciones
Timely (oportuno) -> el mejor momento para escribir un test, que resulta ser antes de escribir el código de producción


Xavi Gost: https://www.youtube.com/watch?v=S4Ueg64xfXQ
Dummy: no hace nada, simplemente para cumplir el contrato
Stub: solo datos
Mock: comportamiento (si ha sido llamado)

principios de XP
- Simplicidad: Lo que se busca, al dejar la puerta abierta a la implementación emergente y gradual (las cuatro reglas del diseño simple de Kent beck)
- Comunicación: conversaciones cara a cara, comunicación directa -> metáfora del teléfono escacharrado
- Feedback: just in time programming. La depuración se hace tediosa; arranca la aplicción que pare en los puntos de interrupción, cuando se puede hacer un test unitario.
- Respeto: desapegarse del código. No tomarlo como algo personal. Predicar con el ejemplo. El respeto del equipo se consigue dejando mejor código de lo que se encuentre.
- Valor: ser transparente y sincero.


builders para simplificar los datos de los tests



Property Based Testing
Mutating Testing

Transformation Priority Premise: PrimeFactors and WordWarp katas
https://martinfowler.com/bliki/PageObject.html

algunas cosas que he aprendido en estos años sobre el agile/xp

- búsqueda de la mejora continua. Quitando los desperdicios a lo largo de todo el ciclo del desarrollo de software.
- individuos motivados.
- búsqueda de la excelencia técnica.
- satisfacer las necesidades del cliente. Resolver con software el problema que tiene el cliente.

Mutate Testing en javascript

 En la comunidad de aprendices de LeanMind se comentó la posibilidad de introducirse en el mutating testing en javascript.

Hace unos meses terminé de leerme el libro de Carlos Blé sobre TDD y me apunté para estudiar mutating testing. 

Lo primero que vi fue este video de Carlos Buenosvinos porque no sabía absolutamente nada.

Encontré varias librerías para hacer mutate testing con javascriot, pero la que más me convenció fue Stryker, porque tiene un activa comunidad que sigue desarrollando. Tiene tests y el código que estuve mirando muy por encima, no me pareció malo.

Me encontré con un video de codemanship que me ayudó muchísimo a entender con más profundidad el mutate testing y la librería Stryker.

Yo creo que esta práctica te ayuda a encontrar casos no contemplados, para generar una red de pruebas en las que tengamos más confianza. Creo que se puede hacer uso de esta práctica una vez que tengamos ya terminada el funcionalidad. No creo que una buena idea lanzarlos cada vez que hagamos un cambio en el código. Creo que es algo a tener en cuenta para nuestros desarrollos, igual que tenemos un analizador de código estático u otros elementos que nos ayudan con nuestros código.

About Waterfall

The author: Winston Walker Royce
The famous paper