Notas
- A medida que los tests se vuelven más específicos, el código de producción se vuelve más genérico
- Abstracción
- 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
- Cada test escrito es una demostración de como el código de producción debe ser usado (caso de uso)
- 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
- 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.
- Escribe un test que no haga nada para asegurar que el entorno de ejecución de tests funciona
- Fake Object
- Generalizar cuando sea posible
- Humble Object
- Jerarquía de los tipos de doble de test
- La artesanía es el estado del conocimiento sobre cómo hacer algo bien y es el resultado de una buen tutela y un montón de experiencia
- Las transformaciones son pequeños cambios de código que cambian el comportamiento y simultaneamente generaliza la solución para el sistema
- 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
- 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
- Mock Object (1)
- No incluyas cosas en tus tests que tu test no necesita
- No reproduzcas la estructura del código de producción en la de los tests
- No uses datos de producción en los tests
- No vayas a por el oro
- Patrón 3A (Arrange, Act and Assert)
- Premisa de prioridad de transformación
- 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)
- Subclase específica de test
- 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
- Test de programador (1)
- Testing GUIs (1)
- Testing sobre bases de datos (1)
- Tu siguiente test a escribir para fallar primero debe ser siempre el más simple
- 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