TDD: una metodología de desarrollo que cambió mi vida

A las 7:15 a.m. Nuestro soporte técnico está inundado de trabajo. Good Morning America acaba de hablar de nosotros y muchos de los que visitan nuestro sitio por primera vez han encontrado errores.

Tenemos mucha prisa. Nosotros, ahora mismo, antes de perder la oportunidad de convertir a los visitantes del recurso en nuevos usuarios, vamos a implementar el fixpack. Uno de los desarrolladores preparó algo. Él piensa que esto ayudará a hacer frente al problema. Colocamos un enlace a la versión actualizada del programa, que aún no ha entrado en producción, al chat de la empresa, y pedimos a todos que lo prueben. Funciona!

Nuestros heroicos ingenieros ejecutan scripts para implementar los sistemas y después de unos minutos la actualización entra en batalla. De repente, el número de llamadas de soporte técnico se duplica. Nuestra solución urgente rompió algo, los desarrolladores se llevaron la culpa y los ingenieros hicieron retroceder el sistema a su estado anterior en ese momento.



El autor del material, cuya traducción publicamos hoy, cree que todo esto podría haberse evitado gracias a TDD.

¿Por qué estoy usando TDD?

No he estado en situaciones como esta durante mucho tiempo. Y no es que los desarrolladores hayan dejado de cometer errores. El hecho es que durante muchos años, en todos los equipos que dirigí e influí, se aplicó la metodología TDD. Los errores, por supuesto, aún ocurren, pero la penetración en la producción de problemas que pueden "derribar" el proyecto ha disminuido a casi cero, a pesar de que la frecuencia de las actualizaciones de software y el número de tareas que deben resolverse durante la actualización han crecido exponencialmente desde entonces. cuando sucedió algo de lo que hablé al principio.

Cuando alguien me pregunta por qué debería ponerse en contacto con TDD, le cuento esta historia y puedo recordar una docena más de casos similares. Una de las razones más importantes por las que cambié a TDD es que esta metodología mejora la cobertura de las pruebas con código, lo que conduce a un 40-80% menos de errores en la producción. Esto es lo que más me gusta de TDD. Esto quita una montaña de problemas de los hombros de los desarrolladores.

Además, vale la pena señalar que TDD salva a los desarrolladores del temor de realizar cambios en el código.

En los proyectos en los que participo, conjuntos de módulos automáticos y pruebas funcionales casi a diario evitan que el código entre en producción, lo que puede interrumpir seriamente el trabajo de estos proyectos. Por ejemplo, ahora estoy mirando 10 actualizaciones automáticas de la biblioteca realizadas la semana pasada, de modo que antes de lanzarlas sin usar TDD, me temo que podrían arruinar algo.

Todas estas actualizaciones se integraron automáticamente en el código y ya se usan en producción. No revisé ninguno de ellos manualmente, y no me preocupé en absoluto de que pudieran tener un efecto negativo en el proyecto. Al mismo tiempo, para dar este ejemplo, no tuve que pensar mucho. Acabo de abrir GitHub, miré fusiones recientes y vi de lo que estaba hablando. La tarea que anteriormente se resolvió manualmente (o, lo que es peor, el problema que se ignoró) ahora es un proceso en segundo plano automatizado. Puede intentar hacer algo similar sin una buena cobertura de código con las pruebas, pero no recomendaría hacerlo.

¿Qué es TDD?

TDD son las siglas de Test Driven Development. El proceso implementado al aplicar esta metodología es muy simple:


Las pruebas detectan errores, las pruebas se completan con éxito, se realiza la refactorización

Estos son los principios básicos para usar TDD:

1. Antes de escribir un código de implementación para alguna característica, escriben una prueba que le permite verificar si este futuro código de implementación funciona o no. Antes de continuar con el siguiente paso, se inicia la prueba y está convencido de que arroja un error. Gracias a esto, puede estar seguro de que la prueba no produce resultados falsos positivos, es un tipo de prueba de las pruebas mismas.
2. Crean una implementación de la oportunidad y aseguran que pase la prueba con éxito.
3. Realice, si es necesario, la refactorización de código. La refactorización, en presencia de una prueba que puede indicarle al desarrollador si el sistema está funcionando correcta o incorrectamente, le da confianza al desarrollador en sus acciones.

¿Cómo puede TDD ayudar a ahorrar el tiempo necesario para desarrollar programas?

A primera vista, podría parecer que escribir pruebas significa un aumento significativo en la cantidad de código del proyecto, y que todo esto lleva a los desarrolladores mucho tiempo extra. En mi caso, al principio, todo era solo eso, y traté de comprender cómo, en principio, es posible escribir código comprobable y cómo agregar pruebas al código que ya se ha escrito.

TDD se caracteriza por una cierta curva de aprendizaje, y mientras un principiante sube por esta curva, el tiempo requerido para el desarrollo puede aumentar en un 15-35% . A menudo esto es exactamente lo que sucede. Pero en algún lugar unos 2 años después del inicio del uso de TDD, algo increíble comienza a suceder. A saber, por ejemplo, comencé, con la redacción preliminar de pruebas unitarias, programando más rápido que antes cuando no se usaba TDD.

Hace unos años, implementé, en el sistema del cliente, la capacidad de trabajar con fragmentos de un videoclip. Es decir, el punto era que sería posible permitir al usuario indicar el comienzo y el final del fragmento de grabación, y recibir un enlace al mismo, lo que permitiría referirse a un lugar específico en el clip, y no a todo este clip.

No trabajé El jugador llegó al final del fragmento y continuó jugando, pero no tenía idea de por qué era así.

Pensé que el problema estaba conectando incorrectamente los oyentes de eventos. Mi código se parecía a esto:

video.addEventListener('timeupdate', () => {  if (video.currentTime >= clip.stopTime) {    video.pause();  } }); 

El proceso para encontrar el problema se veía así: hacer cambios, compilar, reiniciar, hacer clic, esperar ... Esta secuencia de acciones se repitió una y otra vez.

Para verificar cada uno de los cambios introducidos en el proyecto, me llevó casi un minuto gastarlo, y experimenté una increíble cantidad de opciones para resolver el problema (la mayoría de ellos 2-3 veces).

¿Tal vez cometí un error en la palabra clave timeupdate ? ¿Entendí las características de trabajar con la API correctamente? ¿La llamada video.pause() ? Realicé cambios en el código, agregué console.log() , volví al navegador, hice clic en el botón , hice clic en la posición ubicada al final del fragmento seleccionado y luego esperé pacientemente hasta que el clip se reproduzca por completo. Iniciar sesión dentro de la construcción if no condujo a nada. Parecía una pista sobre un posible problema. Copié la palabra timeupdate de la documentación de la API para estar absolutamente seguro de que no cometí un error al ingresarla. Vuelvo a cargar la página, hago clic de nuevo, espero de nuevo. Y nuevamente, el programa se niega a funcionar correctamente.

Finalmente puse console.log() fuera del bloque if . "No ayudará", pensé. Al final, la if era tan simple que simplemente no tenía idea de cómo escribirla incorrectamente. Pero iniciar sesión en este caso funcionó. Me atraganté con el café. "¿Qué demonios es eso?" Pensé

Ley de depuración de Murphy. El lugar del programa que nunca probó, ya que creía firmemente que no podía contener errores, será exactamente el lugar donde encontrará un error después de que, una vez agotado, realice cambios en este lugar solo porque que ya han intentado todo lo que se les ocurrió.

Establecí un punto de interrupción en el programa para entender lo que está sucediendo. clip.stopTime el significado de clip.stopTime . Para mi sorpresa, no estaba undefined . Por qué Miré el código nuevamente. Cuando el usuario selecciona la hora de finalización del fragmento, el programa coloca el marcador para el final del fragmento en el lugar correcto, pero no establece el valor de clip.stopTime . "Soy un idiota increíble", pensé, "no se me debe permitir entrar a las computadoras hasta el final de mi vida".

No me olvidé de esto y años después. Y todo, gracias a la sensación que experimenté, aún encontrando un error. Probablemente sabes de lo que estoy hablando. Con todo esto sucedió. Y, tal vez, todos podrán reconocerse en este meme.


Así es como me veo cuando programo

Si escribiera ese programa hoy, comenzaría a trabajar de esta manera:

 describe('clipReducer/setClipStopTime', async assert => { const stopTime = 5; const clipState = {   startTime: 2,   stopTime: Infinity }; assert({   given: 'clip stop time',   should: 'set clip stop time in state',   actual: clipReducer(clipState, setClipStopTime(stopTime)),   expected: { ...clipState, stopTime } }); }); 

Existe la sensación de que hay mucho más código que en esta línea:

 clip.stopTime = video.currentTime 

Pero ese es el punto. Este código actúa como una especificación. Esto es documentación y prueba de que el código funciona como lo requiere esta documentación. Y, dado que esta documentación existe, si cambio el orden de trabajo con el marcador por el tiempo de finalización de un fragmento, no tengo que preocuparme si durante la introducción de estos cambios violé la operación correcta con el tiempo de finalización del clip.

Aquí , por cierto, hay material útil para escribir pruebas unitarias, el mismo que acabamos de ver.

El punto no es cuánto tiempo lleva ingresar este código. El punto es cuánto tiempo lleva depurar si algo sale mal. Si el código es incorrecto, la prueba dará un excelente informe de error. Inmediatamente sabré que el problema no es el controlador de eventos. setClipStopTime() que es en setClipStopTime() o en clipReducer() , donde se implementa un cambio de estado. Gracias a la prueba, sabría qué funciones realiza el código, qué muestra realmente y qué se espera de él. Y, lo que es más importante, mi colega tendrá el mismo conocimiento, quien, seis meses después de que escribí el código, introducirá nuevas características en él.

Al comenzar un nuevo proyecto, yo, como una de las primeras cosas, configuro un script de observación que ejecuta automáticamente pruebas unitarias cada vez que se cambia un determinado archivo. A menudo programo usando dos monitores. En uno de ellos, se abre la consola del desarrollador, en la que se muestran los resultados de dicho script, en el otro, se muestra la interfaz del entorno en el que escribo el código. Cuando realizo un cambio en el código, generalmente, en 3 segundos, averiguo si el cambio funcionó o no.

Para mí, TDD es mucho más que un seguro. Esta es la capacidad de recibir de manera constante y rápida, en tiempo real, información sobre el estado de mi código. Recompensa instantánea en forma de pruebas aprobadas o un informe instantáneo de errores en caso de que haya hecho algo mal.

¿Cómo me enseñó la metodología TDD a escribir mejor código?

Me gustaría hacer una admisión, incluso admitir que es vergonzoso: no tenía idea de cómo crear aplicaciones antes de aprender TDD y pruebas unitarias. No puedo imaginar cómo me contrataron, pero después de entrevistar a cientos de desarrolladores, puedo decir con confianza que muchos programadores se encuentran en una situación similar. La metodología TDD me ha enseñado casi todo lo que sé sobre la descomposición eficiente y la composición de componentes de software (me refiero a módulos, funciones, objetos, componentes de interfaz de usuario, etc.).

La razón de esto es que las pruebas unitarias obligan al programador a probar componentes aislados uno del otro y de los subsistemas de E / S. Si el módulo se proporciona con algunos datos de entrada, debe proporcionar ciertos datos de salida previamente conocidos. Si no lo hace, la prueba falla. Si lo hace, la prueba tiene éxito. El punto aquí es que el módulo debería funcionar independientemente del resto de la aplicación. Si está probando la lógica del estado, debería poder hacerlo sin mostrar nada en la pantalla o guardar nada en la base de datos. Si está probando la formación de la interfaz de usuario, debería poder probarla sin tener que cargar la página en un navegador o acceder a los recursos de la red.

Entre otras cosas, la metodología TDD me enseñó que la vida se vuelve mucho más fácil si se lucha por el minimalismo al desarrollar componentes de interfaz de usuario. Además, la lógica empresarial y los efectos secundarios deben aislarse de la interfaz de usuario. Desde un punto de vista práctico, esto significa que si usa un marco de interfaz de usuario basado en componentes como React o Angular, puede ser aconsejable crear componentes de presentación que sean responsables de mostrar algo en la pantalla y componentes del contenedor que no están conectados entre sí son mixtos

Un componente de presentación que recibe ciertas propiedades siempre genera el mismo resultado. Dichos componentes se pueden verificar fácilmente mediante pruebas unitarias. Esto le permite averiguar si el componente funciona correctamente con las propiedades y si cierta lógica condicional utilizada en la formación de la interfaz es correcta. Por ejemplo, es posible que el componente que forma la lista no muestre nada más que una invitación para agregar un nuevo elemento a la lista si la lista está vacía.

Conocía el principio de separación de responsabilidades mucho antes de dominar TDD, pero no sabía cómo compartir la responsabilidad entre diferentes entidades.

Las pruebas unitarias me permitieron estudiar el uso de mokas para probar algo, y luego descubrí que burlarse es una señal de que algo podría estar mal con el código . Me sorprendió y cambió por completo mi enfoque de la composición del software.

Todo el desarrollo de software es una composición: el proceso de dividir problemas grandes en muchos problemas pequeños y fáciles de resolver, y luego crear soluciones para estos problemas que forman la aplicación. Tuxing por el bien de las pruebas unitarias indica que las unidades atómicas de la composición no son, de hecho, atómicas. Estudiar cómo deshacerse de mok sin afectar la cobertura del código mediante pruebas me permitió aprender a identificar las innumerables razones ocultas de la fuerte conexión de las entidades.

Esto me permitió, como desarrollador, crecer profesionalmente. Esto me enseñó a escribir código mucho más simple que es más fácil de extender, mantener y escalar. Esto se aplica a la complejidad del código en sí y a la organización de su trabajo en grandes sistemas distribuidos, como las infraestructuras de la nube.

¿Cómo TDD ahorra tiempo al equipo?

Ya he dicho que TDD, en primer lugar, conduce a una mejor cobertura del código con las pruebas. La razón de esto es que no comenzamos a escribir código para implementar alguna característica hasta que escribimos una prueba que verifica el funcionamiento correcto de este código futuro. Primero escribimos una prueba. Luego permitimos que termine con un error. Luego escribimos el código para implementar la oportunidad. Estamos probando el código, recibimos un mensaje de error, logramos la aprobación correcta de las pruebas, realizamos la refactorización y repetimos este proceso.

Este proceso le permite crear una "cerca" a través de la cual solo unos pocos errores pueden "saltar". Esta protección contra errores tiene un efecto sorprendente en todo el equipo de desarrollo. Alivia el miedo al equipo de fusión.

El alto nivel de cobertura del código con pruebas permite al equipo deshacerse del deseo de controlar manualmente cualquier cambio, incluso pequeño, en la base del código. Los cambios de código se convierten en una parte natural del flujo de trabajo.

Deshacerse del miedo a hacer cambios en el código se asemeja al desenfoque de cierta máquina. Si esto no se hace, la máquina finalmente se detendrá, hasta que se lubrique y se reinicie.

Sin este temor, el proceso de trabajar en programas es mucho más tranquilo que antes. Las solicitudes de extracción no se retrasan hasta el final. El sistema CI / CD ejecutará las pruebas y, si las pruebas fallan, detendrá el proceso de realizar cambios en el código del proyecto. Al mismo tiempo, los mensajes de error y la información sobre exactamente dónde ocurrieron serán muy difíciles de no notar.

Este es todo el punto.

Estimados lectores! ¿Utiliza TDD cuando trabaja en sus proyectos?