Me interesa específicamente la siguiente situación. Supongamos que tiene un equipo que escribe código de producción y un equipo que escribe pruebas automáticas. El equipo que escribe pruebas automáticas tiene un marco dedicado destinado a escribir las pruebas automáticas. ¿Debería el equipo de pruebas escribir pruebas unitarias para su marco aunque el marco no se use en producción?¿Realiza pruebas unitarias para código de no producción?
he estado en esa situación y lo que he hecho es utilizar el banco de pruebas para el código de producción también como banco de pruebas para el marco de pruebas . Presumiblemente, todas las características del framework se usaron realmente, por lo que si las pruebas fallaran sin un cambio en el código de producción, entonces debe haber un problema en el marco de prueba.
Funcionó bien-ish: ejecutar esas pruebas llevó mucho más tiempo que tener una prueba-banco de pruebas dedicada, y a veces no las ejecutaba todas y tenía un problema en el servidor de compilación de producción. Diagnosticar tales problemas tomó mucho más tiempo de lo que hubiera tenido con un banco de pruebas.
En general, nunca me sentí cómodo con eso y realmente recomendaría tener pruebas dedicadas para el marco de prueba también. Desde el punto de vista del equipo de pruebas y pruebas, el marco de prueba es código de producción. Y si el marco de prueba alguna vez es utilizado por alguien más, a cuyas suites de prueba no tiene acceso ...
Sí, solo para comprobar que el marco genera suficiente cobertura de prueba.
Infierno sí!
TDD le da una ventaja en el desarrollo, no es solo para complacer al cliente. Le permite escribir código comprobable, reutilizable y modular. Yo probaría unitariamente todo lo que tiene que funcionar, especialmente si esperas cambiarlo a menudo (refactor para agregar nuevas características).
El equipo de pruebas debe hacer todo lo que pueda para aumentar su confianza en los resultados generados por su marco.
Esto incluye pruebas, revisiones de código, los estándares de calidad, ...
Esta pregunta me recuerda una historia: Había una vez una empresa. Esta empresa cree en las pruebas automáticas. Esta creencia es tan fuerte que lleva a crear un grupo cuyo único propósito es escribir estas pruebas automáticas. Todos los creyentes más ardientes pueden unirse a este grupo. ¡Hubo mucho regocijo!
Luego, un día, se descubrió que este grupo de pruebas automáticas, a pesar de su misión, no usa pruebas automáticas para su propio trabajo. Las piedras están fundidas, yada yada.
Solo digo ... Creo que cualquier marco de prueba tendría una cobertura de prueba bastante sólida.
Puedes ver mi pregunta de esta manera. Pero creo que es ingenuo decidir probar el código de no producción basado en este argumento. Mantener las pruebas cuesta dinero al final y, personalmente, creo que debería probar solo el marco de automatización y no todo el laboratorio de automatización. Por otro lado, en el código de producción tu objetivo es probar todo lo que puedas. Esta es la razón de mi pregunta. – Ikaso
Me estoy volviendo loco, pero mi punto es que se pueden aplicar los mismos criterios de evaluación. ¿Por qué escribimos pruebas automatizadas incluso si pudieran agregar un 15% al costo de desarrollo? Al final, la respuesta es _ porque aumenta nuestra confianza en el código_. No es blanco y negro. La pregunta es ¿deberíamos escribir 1 prueba más?Si ya tenemos confianza en el código, o si tener confianza no es tan importante, no es necesario escribir la prueba. Aplicaría esa guía si el consumidor del software es un cliente comercial, un desarrollador compañero o mi hermano pequeño. – ndp