Notas
1-The Disciplines
- Agota el caso más simple actual antes de hacer un test más complejo
- Cada test es un transición de un finitos estado de máquina que describe el comportamiento del sistema
- Chicago school (TDD) (1)
- Chicago vs London (TDD) (1)
- Cuando el código se sienta que está mal, arregla el diseño antes de continuar
- Disciplina
- Dummy Object
- El acto de escribir primero el test te fuerza a diseñar el código fácil de testear y por consiguiente tener menos acoplamiento
- El mecanismo que usan todos los dobles de test es poliformismo
- Escribe un test que no haga nada para asegurar que el entorno de ejecución de tests funciona
- Fake Object
- Generalizar cuando sea posible
- Jerarquía de los tipos de doble de test
- Las tres leyes de TDD
- Ley de boy scout
- London school (TDD) (1)
- Los spy objects son frágiles. Cualquier cambio en el algoritmo rompe virtualmente todos los tests, forzando a tener que arreglarlos o incluso reescribirlos
- Los tests hechos con TDD como documentación
- Mock Object (1)
- No incluyas cosas en tus tests que tu test no necesita
- No uses datos de producción en los tests
- No vayas a por el oro
- Patrón 3A (Arrange, Act and Assert)
- Principio de incertidumbre de TDD
- Refactoring como cuarta ley de TDD
- Responsabilidad extraviada
- Si debes implementar demasiado para que el test actual pase, elimina ese test y escribe uno más simple que puedas pasar más fácilmente.
- Spy test double
- Stairstep tests
- Stub (1)
- TDD cómo técnica general para escribir cualquier algoritmo o programa de forma incremental y determinativa
- TDD es complejo porque los test deben estar diseñados para ajustarse al código sin estar acoplado a este y debe cubrir casi en su totalidad tardando la ejecución del orden de segundos
- Tu siguiente test a escribir para fallar primero debe ser siempre el más simple
2-Test Design
- A medida que los tests se vuelven más específicos, el código de producción se vuelve más genérico
- Humble Object
- Las transformaciones son pequeños cambios de código que cambian el comportamiento y simultaneamente generaliza la solución para el sistema
- Los tests necesitan ser diseñados como otra parte más del sistema en construcción para evitar que sean frágiles y difíciles de mantener
- No reproduzcas la estructura del código de producción en la de los tests
- Premisa de prioridad de transformación
- Subclase específica de test
- Test de programador (1)
- Testing GUIs (1)
- Testing sobre bases de datos (1)
6-Simple Design
- Cada test escrito es una demostración de como el código de producción debe ser usado (caso de uso)
- El mejor diseño para un sistema es el más simple que cumpla todos los requisitos funcionales mientras, al mismo tiempo, tenga gran flexibilidad al cambio.
- Un diseño simple es un diseño en el cual las políticas de alto nivel ignoran los detalles de bajo nivel. De esta manera, están aislados y no reciben impacto de cambios en detalles de bajo nivel