Slides resumen de los puntos más importantes del capítulo 9 del Clean Code de Uncle Bob Martin.

1. 9.
Unit Testing

2. Unit test
• Una unidad es la parte testable más pequeña del software.
• Test de unidades/componentes individuales del software.
• No es un test de una clase.
• Se tiene que ejecutar rápido para poder ejecutarse muchas
veces…sino no se ejecuta.
• Es muy limitado en su alcance. Si el test falla, es obvio
donde buscar el problema.

3. Unit Tests vs TDD
• No es lo mismo:
• Unit test -> Escribir un test.
• TDD -> Escribir tests aplicando la metodología.

5. Leyes de TDD
• No escribir código de producción sin escribir su
respectivo test unitario fallido.
• Escribir solo lo necesario para que un test falle.
• No escribir más código que el necesario para que
el test fallido deje de fallar.

6. La realidad
• La mayoría del tiempo estamos:
• Leyendo más que escribiendo
• Manteniendo código.
• Arreglando bugs
• Desarrollando nuevas funcionalidades.

7. Código flexible
• Los tests unitarios hacen nuestro código flexible,
mantenible y reusable.
• Si tienes tests, tienes menos miedo a hacer
cambios en el código.
• Los tests permiten los cambios.

8. Mantener los tests limpios
• Test sucios -> No test -> !Flexibilidad código de
producción.
• Los tests tienen que cambiar en medida que lo
hace el código de producción.
• Código de los test es tan importante como el de
producción.

9. Legibilidad de los tests
• Más importante en tests incluso que en código de
producción.
• Claridad, simplicidad y densidad de la expresión.
• Eliminar detalles innecesarios.
• Utilizar un lenguaje de dominio para los tests.

10. Tests limpios
• Una única aserción.
• Testar una sola cosa al mismo tiempo (fijarse en
nombre y las aserciones).
• SetUp / Before.
• Utilizar una base de test.

11. Tests limpios
• Preparación.
• Ejecución.
• Aserción.

12. FIRST
• Fast.
• Independent.
• Repeatable.
• Self-Validating.
• Timely.

13. Key points
• Hacer tests no significa no bugs ni buen código.
• No anticiparse e ir paso a paso.
• La solución y su diseño emerja de los tests.
• Facilita un diseño desacoplado.
• Nos obliga a escribir el mínimo de funcionalidad necesaria, evitando
sobrediseñar.
• Los test unitarios actúan como documentación que no se queda
obsoleta.

14. Por qué hacemos tests
Calidad
Clean code
Profesionalidad
Hacer lo correcto
Economics