¿Cuáles son tus trucos de desarrollo favoritos basados ​​en pruebas?

Aquí hay un buen truco para enseñar a otros el desarrollo basado en pruebas: descubrí que el emparejamiento de Ping Pong puede ayudar a TDD y la programación de pares a complementarse bastante bien.

El emparejamiento de Ping Pong es cuando una persona escribe la prueba fallida, luego otra escribe el código que la hace pasar. El emparejamiento puede ayudar a que un ingeniero que no esté familiarizado con TDD aumente rápidamente. El aspecto Ping Pong también ayuda a evitar que su pareja empareje el teclado. 😉

TDD se convirtió en una práctica central para mí cuando comencé a usarlo para diseñar soluciones de código. Comienzo en la parte superior del problema y luego TDD en mi camino hacia cada pieza de la pila, diseñando la solución al problema utilizando las pruebas. Al principio no era natural, así que me obligué a no escribir código que no pasara una prueba. Ahora es una segunda naturaleza y me cuesta mucho escribir código sin pruebas. Los beneficios me parecen obvios ahora, pero no lo hicieron al principio.

Beneficios de TDD:

1. Para poder burlarse del código, termina muy modularizado, lo que mantiene enfocado cada método de clase. Mis controladores se han vuelto muy pequeños (solo me preocupa lo que el cliente necesita), y los servicios usan más clases de utilidad.
2. Ya no corro en senderos de conejos de ingeniería. Agregar cosas que la gente podría necesitar algún día fue un elemento principal de la agenda para mí en el pasado, pero ahora solo escribo el código que sé que necesitamos (a través de una prueba). Esto ahorra mucho tiempo y me ha obligado a admitir que todas mis características sobredimensionadas casi nunca se usaron de todos modos.
3. La refactorización por último pone la solución primero, pero evita los olores de código. En los viejos tiempos, refactorizaba cuando no me gustaba a dónde iban las cosas. Esto fue subjetivo y desenfocado, lo que llevó a una gran cantidad de tiempo perdido. Ahora, a través de TDD, me estoy enfocando en hacer que el código funcione primero, luego me preocupo por cómo está estructurado. Este enfoque realmente funciona.
4. Refactorizar es siempre una mejora, y no una reescritura causada por Uy. Mi malentendido de la solución ha llevado a muchas reescrituras en el pasado, lo que significa que las reescrituras no siempre fueron una mejora real en el código. Ahora cada paso de refactorización a través del código se mueve en una mejor dirección.
5. Nuestros requisitos han mejorado mucho. Solo escribir código para pasar una prueba lo obliga a pensar en los casos de prueba que realmente necesita, lo que realmente significa que tiene que ser claro y minucioso en sus requisitos. Debido a TDD, todo mi equipo escribe mejores requisitos y reconoce mejor aquellos que están escritos de manera ambigua.

Creo que podría seguir y seguir con esta lista, pero me detendré aquí.