Como desarrollador profesional, ¿es aceptable no escribir pruebas unitarias? [cerrado]

¿Solo se pregunta sobre los pros y los contras de las pruebas unitarias TDD / automatizadas y busca la opinión de la comunidad sobre si es aceptable que los desarrolladores profesionales escriban aplicaciones sin apoyar las pruebas unitarias?

¿Para probar qué?

Si habla de una cobertura de código del 100%, es extremadamente raro, no es útil y a menudo imposible. Del mismo modo, probar el código relacionado con CRUD es una pérdida de tiempo, y sería muy poco profesional pasar horas escribiendo código que no necesita en lugar de hacer algo realmente útil.

Ahora, como desarrollador, debe saber cómo escribir pruebas unitarias y dónde las necesita.

Teoría

Existe una idea errónea de que las pruebas unitarias son para probar "unidades" .
Las pruebas unitarias, así como todas las demás pruebas, prueban la funcionalidad . Simplemente no se puede probar nada más.

Sin embargo, la funcionalidad de un sistema complejo a menudo no se puede probar de manera efectiva.
Digamos que un usuario presiona el botón "Eliminar" y no sucede nada. ¿Por qué? Un error puede estar dentro de una base de datos, una conexión puede estar rota, una lógica central puede funcionar mal, o incluso una operación puede tener éxito pero la interfaz no se actualizó correctamente. Cada capa puede contener muchas funciones que se llaman entre sí, y no siempre está claro dónde está el error.
Las pruebas unitarias se basan en un paradigma de separar componentes y probarlos individualmente.

Una vez más, no garantiza que todo el sistema funcione, pero simplifica las pruebas.

TDD no es un requisito en sí mismo. Simplifica la codificación al obligar a un desarrollador a responder primero, "¿qué voy a codificar realmente?".

Costos

Muchos piensan que al no escribir exámenes, ahorran su tiempo. Incorrecto. Pensando estratégicamente, el costo de un error aumenta exponencialmente con el tiempo desde la aparición hasta la detección.

Supongamos que comete un error en su código y lo detecta y corrige el mismo día. El costo es de $ X .
Supongamos que el error no se detecta y pasa a la compilación interna semanal. Afortunadamente, el control de calidad lo detectó, provocó un error en el rastreador de errores, el tema fue objeto de una discusión de 5 minutos en una reunión de 5 personas, etc. Finalmente, lo solucionó. El costo es la suma de la mano de obra gastada por todos, y puede ser $ 3 * X en este caso.
¿Qué pasa si el error fue a la prueba beta e involucra a más personas? Digamos Vamos, $ 10 * X .
Si permanece sin ser detectado durante mucho tiempo, acudió a 1,000 clientes (¡con suerte, no a un millón!), 10 de ellos lo detectaron, plantearon una discusión con su personal de soporte, algunos pueden llamar a su jefe, sus compañeros de equipo intentan reproducirlo , etc., etc. Finalmente, el error regresa a usted y lo arregla. ¿Cuánto en total? Así más de $ 50 * X .

Como puede ver, tarde o temprano un error volverá a usted (o su colega). La única diferencia es cuándo sucede y cuánto costaría.
Las pruebas unitarias acortan el ciclo de vida de los errores y, por lo tanto, reducen los costos.

Pro

• Las pruebas unitarias permiten al desarrollador codificar mejor . Tan simple como eso.
• Te dejan ahorrar tu tiempo;
• Disminuyen los costos;
• Las pruebas unitarias conviven con el código que prueban. Ante cualquier solicitud de cambio (que ocurre todo el tiempo), las pruebas se adaptarán.

Contras

Puedo ver una sola excusa para no escribir exámenes. Si está escribiendo un prototipo, por ejemplo, algo que nunca irá a las otras personas. O tal vez estás escribiendo algo para un solo uso.

Claro, es aceptable no escribir pruebas unitarias para pequeñas utilidades internas de ayuda, o herramientas de prueba, o escenarios en los que las empresas realmente realmente necesitan otras cosas además de la calidad y usted, como desarrollador profesional, descubre que puede hacer que el software funcione y funcione igual de rápido sin.

En mi experiencia, el 95% de los errores que pueden ser detectados por las pruebas unitarias provienen de llamadas a la capa de datos, especialmente después de los cambios en el diseño de la base de datos. Si está utilizando una base de datos, simplemente pruebe cada método que use para acceder a ella. Las pruebas ni siquiera necesitan ser elaboradas, solo controles de cordura.

En respuesta a su pregunta: si accede a una base de datos y es un desarrollador profesional, entonces debería usar pruebas unitarias. De lo contrario, depende.

Realmente depende de cómo se usará la aplicación. ¿Es esta una aplicación de misión crítica? ¿O es una aplicación de verificación simple que solo usan los desarrolladores internamente? Cuando trabaje en las aplicaciones principales de su empresa, debe haber tantas pruebas unitarias como sean necesarias para garantizar que las decisiones comerciales estén cubiertas. Dependiendo de su empresa, esas son las aplicaciones que los clientes ven y los errores pueden costar el dinero. Cuando se hace bien, las pruebas unitarias pueden ser de gran ayuda para garantizar que sus aplicaciones funcionen cuando se implementen. Pero no es una cura para todos y las pruebas en humanos aún deben hacerse. Las aplicaciones internas simples (o auxiliares) no necesitan pruebas unitarias, pero aún deben escribirse bien.

TDD no se trata solo de escribir pruebas primero. Se trata de asegurarse de que su código sea fácilmente comprobable. Y la mayoría de las veces, el código fácilmente comprobable también es más fácil de leer / depurar / mantener. La mayoría de las veces, el código fácilmente comprobable también sigue patrones y principios OO como SOLID. Yo diría que, como desarrollador profesional, su código siempre debe escribirse de esa manera.

Definitivamente no quieres "ninguna prueba". Si escribe pruebas unitarias, tiene al menos cierta seguridad de que su código coincide con sus pruebas (aunque necesitaría asegurarse de que sus pruebas coincidan con su especificación).

Sin embargo, no has terminado si todo lo que tienes son pruebas unitarias. Probablemente aún necesite hacer pruebas de integración y pruebas de extremo a extremo (y con el tiempo acumule casos de prueba para detectar regresiones de errores).

Voy a arriesgarme aquí y decir que es principalmente subjetivo y depende de tus objetivos. tl; dnr: Es bueno hacerlo, pero ser dogmático al respecto solo generará más problemas.

Las pruebas de TDD / Unidad mejorarán la estabilidad de su código. Hacen que sea más fácil hacer cambios sin conocer la base del código realmente bien, te permiten refactorizar más rápido, te permiten estar seguro de que no estás haciendo algo tonto. Las pruebas unitarias también pueden ser una pérdida de tiempo. Tiempo que podría pasar escribiendo código. También puede permitirte engañarte pensando que tu código funciona cuando no funciona si los sigues a ciegas.

Si está trabajando para una empresa que respalda las mejores prácticas y le da tiempo para implementarlas y desea una aplicación que dure, entonces es realmente mejor para todos usar y practicar pruebas unitarias y revisiones de código. Tener un equipo de control de calidad puede ser un sustituto aceptable si los desarrolladores no abusan de él. Si está escribiendo un prototipo (incluso uno de producción) puede ser más rápido que simplemente hacer pruebas de humo.

Si está trabajando en algo donde un desastre no va a ser el fin del mundo, probablemente tenga menos cobertura. ¿Transacciones financieras? Un montón. Si tiene un equipo de desarrolladores fuertes que conocen la base de código, trabajan bien juntos y no hay rotación, entonces probablemente necesite menos cobertura. Etc.

Entonces, probablemente va a ser alguna función

• Tamaño del equipo / rotación
• Vida útil deseada de la aplicación
• La aplicación y cuán críticos son los fallos
• Tiempo proporcionado para implementar las mejores prácticas relacionadas con el cronograma de desarrollo
• Aptitud del equipo (esto no significa que ser un buen programador significa que no debe escribir pruebas unitarias, pero un equipo sin desarrolladores junior podría volar por el asiento del pantalón con más éxito)

Hay muchas situaciones en las que no escribir pruebas unitarias sería aceptable. TDD está 'en' ahora, pero no es una bala de plata.

¡Es profesional escribir pruebas de unidad mantenibles que le ahorrarán tiempo y lágrimas!

Hay un misconception that Unit test finds bugs. Bueno, eso simplemente NO es cierto para todos los casos. Las pruebas unitarias no se tratan de encontrar errores o detectar regresiones. Es por definición, examine each unit of your code separately. Pero cuando su aplicación se ejecuta de verdad, todas esas unidades tienen que trabajar juntas, y el conjunto es más complejo y sutil que la suma de sus partes probadas independientemente.

Por lo tanto, el objetivo de las pruebas unitarias (dentro del proceso TDD) se trata de diseñar componentes de software de manera robusta.

Editar: hay una excepción en la que las pruebas unitarias realmente detectan errores. Es cuando refactoriza o reestructura el código de una unidad pero sin querer cambiar su comportamiento. En este caso, las pruebas unitarias a menudo pueden decirle si el comportamiento de la unidad ha cambiado.

Como desarrollador profesional, ¿es aceptable no escribir pruebas unitarias?

No.

Sin duda, esta debería ser una de las primeras lecciones que aprende un estudiante más nuevo. Usted debe desarrollar pruebas unitarias para probar que funciona su código antes de informar de control de calidad que su código está listo para la prueba. De lo contrario, se inflarían los costos del proyecto y se reduciría la moral del equipo.

¿Cuán exhaustivas deberían ser estas pruebas unitarias?

Aquí está la prueba de fuego: si QA descubre un error en su código, ¿se sentirá cómodo usando su (s) prueba (s) de unidad para demostrar su diligencia debida a su jefe?

Si su respuesta es 'No', entonces debe elaborar una mejor prueba de unidad (o pruebas).
Si su respuesta es 'Sí', entonces su código está listo para la verificación.

Como desarrollador profesional, ¿es aceptable no escribir pruebas unitarias automatizadas ?

Si.

Particularmente si el tiempo y el esfuerzo dedicado a escribir pruebas unitarias automatizadas superarían el beneficio obtenido por la prueba. Esto incluye, pero no está restringido a, código UI que puede ser difícil de burlar.

Énfasis: no digo que sea imposible escribir pruebas unitarias automatizadas para el código de la interfaz de usuario. Solo digo que, en mi experiencia, a veces es difícil escribir pruebas unitarias automatizadas para algún código de IU.