Meh Si una persona ha trabajado en una empresa durante años para obtener el estatus de senior y no ha escrito ningún caso de prueba, entonces realmente debería tratar de convencer a los líderes empresariales para que lo incorporen. Si el negocio quiere pruebas unitarias, entonces es mejor que crea que los desarrolladores escribirán pruebas. Si la empresa no quiere pruebas unitarias, entonces no debería escribir pruebas unitarias.
Triste pero cierto. Puede convencer al programador senior todo lo que quiera, pero si los gerentes y las personas que le pagan dinero no están a bordo, entonces no hay nada que el programador senior pueda hacer.
Irónicamente, esto se pierde en los programadores que piensan que siempre debes escribir pruebas y, si no lo estás, es en ese programador. Estos programadores que piensan que nunca deberían ocupar puestos de alto nivel o de liderazgo, porque cualquier programador que vaya en contra de los intereses comerciales no debería o probablemente no estará en la posición de gerencia por mucho tiempo.
- Cómo hacer que mi computadora funcione más rápido
- ¿Es bueno tener más y más parámetros capturados para los datos de calificación crediticia? ¿Los algoritmos comienzan a fallar / se vuelven inexactos si hay demasiados atributos en los datos? ¿Cómo se pueden erradicar los parámetros que no son muy útiles?
- ¿Cuál es la historia detrás del término 'Minería de datos'?
- ¿Qué avance tecnológico u otro ha hecho posible la computación en la nube hoy? ¿Cuál es la diferencia entre los conceptos de computación en la nube y de computación en red como una WAN?
- ¿Cuál es la diferencia entre evaluación y validación en el aprendizaje automático?
Todavía recuerdo la entrevista en la que me preguntaron si había escrito pruebas en la compañía en la que estaba y me rechazaron, cuando tuve que mencionar que no. Luego, dentro del primer mes de un nuevo trabajo, estoy escribiendo pruebas unitarias y funcionales. Oh, la ironía. El hecho de que alguien diga que no, no significa que no pueda o no quiera.
Editar: siento que debería aclarar. La razón por la que no lo hice, es que si el programador senior no está escribiendo pruebas en su propio tiempo y nunca lo ha hecho, entonces probablemente no hay nada que pueda decir. Para ese programador, si tienen 3 errores por cada 1000+ líneas y su proyecto no es tocado por nadie más, entonces probablemente sientan y probablemente tengan razón de que tendrían un ROI más alto al no perder el tiempo, ya sea solos. o en la empresa escribiendo algo que sienten sería una pérdida de tiempo y dinero.
Lleva tiempo entrenar cómo escribir pruebas, hay muchos tipos de casos de prueba que proporcionan diferentes niveles de cobertura y ROI. Las pruebas unitarias son buenas, pero no atraparán todo. También necesita pruebas funcionales y pruebas del sistema. Cuantos más tipos de pruebas, mejor es la cobertura, más errores y regresiones se detectarán antes. Escribir bien las pruebas también requiere experiencia.
Un ejemplo de la vida real: nuestro programador principal tardó 2 días en escribir pruebas funcionales de xUnit. Estas pruebas fueron el mínimo y fueron bastante inútiles. Es decir, se perdieron alrededor de 16 horas por algo que podría haberse logrado utilizando Postman o el navegador en 5 minutos.
Una idea común es que es mejor hacerse pruebas que no hacerlo. Eso solo es cierto si el código nunca cambia. Las pruebas terribles, al igual que la documentación terrible, son peores que ninguna. Recuerde esto, si las pruebas no valen nada, entonces alguien tendrá que pasar tiempo preguntando, sacando la especificación original y si el código cambia, las pruebas deben actualizarse.
Eso puede parecer algo pequeño y lo es, si se hace tan pronto como cambie el código, pero el equipo del mundo real, no apostaría por ello. Debe detectarse con solicitudes de extracción, pero eso depende de la persona que realiza la solicitud de extracción para recordar que las pruebas deben agregarse o actualizarse.
Lo que estoy tratando de decir es que las pruebas son importantes porque establece una línea de base para los casos de uso que funcionan en qué condiciones. También son útiles para encontrar regresiones cuando ocurren y ahorra dinero. Los estudios han demostrado que cuanto antes encuentre un error y lo repare, más dinero se ahorrará.
Las pruebas tienen una manera de hacer que los programadores se atasquen en el pensamiento mágico, ya que las pruebas proporcionan una barrera mágica contra los errores. Nunca tendrá suficientes pruebas y nunca podrá probar todas las condiciones que el código podría fallar.
Si un programador puede escribir código que no requiere las pruebas unitarias mínimas, ¿por qué debería perder el tiempo confirmando que su código ya funciona? ¿Para otros? Si el programador está haciendo su trabajo, no debería tener que modificar su código en absoluto. Por supuesto, hay un toma y daca, pero los programadores experimentados lo saben y programan en consecuencia.
Con eso, mi justificación para escribir pruebas, es que a menudo solo toman un poco más de tiempo que las pruebas manuales y preferiría no tener que probar manualmente lo mismo más de una vez. Soy flojo, escribir pruebas me permite ser flojo, así que escribo pruebas. Aunque en su mayor parte, la mayoría de las pruebas serán verdes la primera vez.
Para mí, si puedo encontrar incluso un error del esfuerzo, entonces valió la pena.
