¿Cuál es mejor, un desarrollador de software que escribe las pruebas unitarias pero no cumple con la fecha límite del proyecto o un desarrollador de software que ignora las pruebas unitarias y cumple con la fecha límite del proyecto?

¿Cuál es mejor, un desarrollador de software que escribe las pruebas unitarias pero no cumple con la fecha límite del proyecto o un desarrollador de software que ignora las pruebas unitarias y cumple con la fecha límite del proyecto?

La forma en que está formulada la pregunta, la respuesta que parece estar buscando es que está bien no escribir pruebas unitarias. ¡Envíalo! ¡Hiciste la fecha límite! ¡Felicidades!

Pero esa no es la respuesta real. La verdadera respuesta es “depende”.

Especialmente si no eres un desarrollador junior, parte de lo que te pagan es tu juicio cuando se trata de software. Una pequeña parte de eso es poder costar características con una precisión razonable. Eso significa que, a menos que sus características y programación estén impuestas externamente (lo cual es un error), la parte en la que no está escribiendo pruebas o no enviando a tiempo es probablemente su culpa, en cierta medida.

Es posible (¡en serio!) Que su código se descarte en gran medida y que esté perdiendo el tiempo hacia el final de su proyecto escribiendo pruebas cuando debería enviarlo. De nuevo, deberías estar usando tu juicio.

Sin embargo, ese no suele ser el caso. Por lo general, su código no es descartable. Si las cosas van bien, su empresa seguirá construyendo sobre el código que está enviando ahora durante años. Tal vez las personas externas dependerán del comportamiento del código. Y al no escribir pruebas, está acumulando deudas técnicas.

Debe darse cuenta de que no escribir esas pruebas unitarias tiene algunos inconvenientes:

1. Es más probable que el código que está escribiendo no sea comprobable que si hubiera escrito las pruebas. Es más probable que termine con dependencias que son difíciles de romper, y con clases y métodos que hacen demasiado.
2. Se vuelve más difícil cambiar el código en esa área con confianza. Cada vez que realice un cambio allí, puede romper algo que sus pruebas deberían detectar. Entonces, estás escribiendo “IOU 1 set of tests” y lo dejas caer en el frasco de cosas por hacer.
3. Imagine este escenario: envía sin las pruebas. Te das cuenta de que has incurrido en deudas técnicas y tienes un elemento en el cronograma para escribir las pruebas, lo que obtienes rápidamente. Y descubres que las cosas no están del todo bien. El comportamiento en algunos casos no es lo que debería ser, y lo ha enviado. ¿Qué tan fácil es cambiar ese comportamiento ahora? (Nuevamente, la respuesta correcta es “depende”). ¿Qué tan probable es que alguien dependa de su comportamiento defectuoso, o evite su error, solo para descubrir que su solución se rompe si arregla su código más tarde?
4. Incurrir en deudas técnicas rara vez es excepcional. Si su equipo es del tipo que lo alienta a incurrir en deudas para hacer el cronograma, está haciendo lo mismo con otros miembros de su equipo, y muchos de ellos escriben cada vez menos pruebas. Su código será mucho, mucho más difícil de mantener.

Un desarrollador solo cumple la fecha límite si completa todo el trabajo, incluidas las buenas pruebas unitarias. Un desarrollador que ignora las pruebas unitarias no tiene idea de si ha cumplido el plazo del proyecto o no, ya que su código no ha sido probado.

Muchos desarrolladores “rápidos” trabajan en empresas donde la responsabilidad de corregir errores está separada de la responsabilidad de la codificación inicial. En este tipo de organización, a otra persona se le puede asignar la tarea de corregir los errores que registran en el repositorio. De hecho, es una forma muy destructiva de trabajar, pero puede ganar la reputación de desarrollador como programador rápido si su jefe no está prestando demasiada atención. Tengo que decir que estos son algunos de mis compañeros de trabajo menos favoritos.

Es necesario terminar todo el trabajo. Si no puede cumplir con la fecha límite, no puede. Pero afirmar que se cumple el plazo cuando no has terminado el trabajo es solo una mentira.