Hay una serie de preguntas en este sitio que brindan mucha información sobre los beneficios que se pueden obtener de las pruebas automatizadas. Pero no vi nada que representara el otro lado de la moneda: ¿cuáles son las desventajas? Todo en la vida es una compensación y no hay balas de plata, por lo que seguramente debe haber algunas razones válidas para no hacer pruebas automatizadas. ¿Qué son?
Aquí hay algunos que se me ocurrieron:
- Requiere más tiempo de desarrollador inicial para una función determinada
- Requiere un mayor nivel de habilidad de los miembros del equipo
- Aumentar las necesidades de herramientas (corredores de prueba, marcos, etc.)
- Se requiere un análisis complejo cuando se encuentra una prueba fallida: ¿esta prueba está obsoleta debido a mi cambio o me dice que cometí un error?
Editar
Debo decir que soy un gran defensor de las pruebas automatizadas, y no estoy buscando ser convencido de hacerlo. Estoy tratando de entender cuáles son las desventajas, de modo que cuando voy a mi empresa para presentar un caso, no parece que esté lanzando la próxima bala de plata imaginaria.
Además, soy explícitamente no busco a alguien para disputar mis ejemplos anteriores. Estoy tomando como cierto que debe haber algunas desventajas (todo tiene compensaciones) y quiero entender cuáles son.
fuente
Respuestas:
Casi clavaste los más importantes. Tengo algunas adiciones menores, más la desventaja de que las pruebas realmente tienen éxito, cuando realmente no quieres que lo hagan (ver más abajo).
Tiempo de desarrollo: con el desarrollo basado en pruebas, esto ya se calcula para las pruebas unitarias, pero aún necesita pruebas de integración y del sistema, que también pueden necesitar código de automatización. El código escrito una vez generalmente se prueba en varias etapas posteriores.
Nivel de habilidad: por supuesto, las herramientas tienen que ser compatibles. Pero no es solo tu propio equipo. En un proyecto más grande, es posible que tenga un equipo de prueba separado que escriba pruebas para verificar las interfaces entre el producto de su equipo y el de otros. Muchas personas más tienen que tener más conocimiento.
Necesidades de herramientas: eres perfecto allí. No hay mucho que agregar a esto.
Pruebas fallidas: este es el verdadero error (para mí de todos modos). Hay muchas razones diferentes, cada una de las cuales puede verse como una desventaja. Y la mayor desventaja es el tiempo requerido para decidir cuál de estas razones se aplica realmente a su prueba fallida.
Pruebas no fallidas: estas también son una desventaja y pueden ser bastante malas. Ocurre principalmente, cuando cambias las cosas y te acercas a lo que Adam respondió. Si cambia algo en el código de su producto, pero la prueba no lo explica en absoluto, entonces le da esta "falsa sensación de seguridad".
Un aspecto importante de las pruebas no fallidas es que un cambio de requisitos puede hacer que un comportamiento anterior se vuelva inválido. Si tiene una trazabilidad decente, el cambio de requisitos debería poder coincidir con su código de prueba y sabe que ya no puede confiar en esa prueba. Por supuesto, mantener esta trazabilidad es otra desventaja. Y si no lo hace, termina con una prueba que no falla, pero que en realidad verifica que su producto funciona incorrectamente . En algún lugar en el camino, esto te golpeará ... generalmente cuando / donde menos lo esperas.
Costos de implementación adicionales: no solo ejecuta pruebas unitarias como desarrollador en su propia máquina. Con las pruebas automatizadas, desea ejecutarlas mediante confirmaciones de otros en algún lugar central para averiguar cuándo alguien rompió su trabajo. Esto es bueno, pero también debe configurarse y mantenerse.
fuente
Después de comenzar a probar pruebas automatizadas en nuestro equipo, la mayor desventaja que he visto es que es muy difícil aplicar el código heredado que no fue diseñado teniendo en cuenta las pruebas automáticas. Sin duda, mejoraría nuestro código a largo plazo, pero el nivel de refactorización necesario para las pruebas automatizadas mientras se conserva nuestra cordura es una barrera muy alta para la entrada a corto plazo, lo que significa que tendremos que ser muy selectivos acerca de la introducción automatizada pruebas unitarias para cumplir con nuestros compromisos a corto plazo. En otras palabras, es mucho más difícil pagar las tarjetas de crédito cuando ya tienes una gran deuda técnica.
fuente
Quizás la desventaja más importante es ... las pruebas son el código de producción . Cada prueba que escribe agrega código a su base de código que debe mantenerse y admitirse. No hacerlo conduce a pruebas en las que no crees los resultados, por lo que no tienes otra opción. No me malinterpreten: soy un gran defensor de las pruebas automatizadas. Pero todo tiene un costo, y este es uno grande.
fuente
No diría que estas son desventajas totalmente aplicables, pero las pocas que golpeo más son:
La cobertura de prueba que es irregular puede conducir a una falsa sensación de seguridad. Si realiza una refactorización y utiliza las pruebas para demostrar su validez, ¿qué ha demostrado que sus pruebas pueden demostrarlo?
El tiempo que lleva crear la prueba a veces es un problema para nosotros. Nuestras pruebas automatizadas no solo incluyen pruebas unitarias, sino que también usan pruebas de casos. Estos tienden a ser más amplios y requieren contexto.
Por supuesto, mi perspectiva es de una aplicación que es más antigua que sus pruebas unitarias.
fuente
Yo diría que el principal problema con ellos es que pueden proporcionar una falsa sensación de seguridad . El hecho de que tenga pruebas unitarias no significa que realmente estén haciendo nada y eso incluye probar adecuadamente los requisitos.
Además, las pruebas automatizadas también pueden incluir errores en sí mismos , por lo que surge la pregunta sobre si las pruebas unitarias deben probarse a sí mismas para no lograr necesariamente nada.
fuente
Aunque las pruebas de automatización tienen muchas ventajas, también tiene sus propias desventajas. Algunas de las desventajas son:
Algunas de las desventajas anteriores a menudo restan del beneficio obtenido de los scripts automatizados. Aunque las pruebas de automatización tienen pros y callos, se adapta ampliamente en todo el mundo.
fuente
Hace poco hice una pregunta sobre las pruebas en el desarrollo de juegos , esto es, por cierto, cómo supe de esto. Las respuestas allí señalaron algunas desventajas curiosas y específicas:
El cuarto punto me hace recordar alguna experiencia mía. Trabajé en una empresa muy delgada, orientada a XP, administrada por Scrum, donde las pruebas unitarias eran muy recomendables. Sin embargo, en su camino hacia un estilo más delgado y menos burocrático, la compañía simplemente descuidó la construcción de un equipo de control de calidad: no teníamos evaluadores. Con tanta frecuencia, los clientes encontraron errores triviales usando algunos sistemas, incluso con una cobertura de prueba de> 95%. Entonces agregaría otro punto:
Además, en esos días estaba pensando en la documentación y reflexioné sobre una hipótesis que puede ser válida (en menor medida) para las pruebas dos. Simplemente sentí que el código evoluciona tan rápido que es bastante difícil hacer documentación que siga esa velocidad, por lo que es más valioso pasar tiempo haciendo que el código sea legible que escribir documentación pesada y fácilmente obsoleta. (Por supuesto, esto no se aplica a las API, sino solo a la implementación interna). La prueba sufre un poco del mismo problema: puede ser demasiado lenta para escribir en comparación con el código probado. OTOH, es un problema menor porque las pruebas advierten que están desactualizadas, mientras que su documentación permanecerá en silencio siempre que no la vuelva a leer con mucho cuidado .
Finalmente, a veces encuentro un problema: las pruebas automatizadas pueden depender de las herramientas, y esas herramientas pueden estar mal escritas. Comencé un proyecto usando XUL hace algún tiempo y, hombre, es doloroso escribir pruebas unitarias para dicha plataforma. Comencé otra aplicación usando Objective-C, Cocoa y Xcode 3 y el modelo de prueba era básicamente un montón de soluciones.
Tengo otras experiencias sobre las desventajas de las pruebas automatizadas, pero la mayoría de ellas se enumeran en otras respuestas. No obstante, soy un defensor vehemente de las pruebas automatizadas. Esto ahorró mucho trabajo y dolor de cabeza y siempre lo recomiendo por defecto. Creo que esas desventajas son solo simples detalles en comparación con los beneficios de las pruebas automatizadas. (Es importante proclamar siempre su fe después de comentar herejías para evitar el auto da fé).
fuente
Dos que no se mencionan son:
He sido parte de los esfuerzos automatizados de control de calidad en los que me llevó medio día ejecutar las pruebas, porque las pruebas fueron lentas. Si no tiene cuidado al escribir sus pruebas, su conjunto de pruebas también podría resultar de esta manera. Esto no suena como un gran problema hasta que ahora esté manejando ese tiempo, "Oh, acabo de cometer una solución, pero tomará 4 horas probar la corrección".
Algunos métodos de prueba (como la automatización de la interfaz de usuario) parecen romperse cada vez que se da la vuelta. Especialmente doloroso si su script, por ejemplo, bloquea el proceso de prueba porque está esperando que aparezca un botón, pero el botón ha cambiado de nombre.
Estas son dos cosas que puede solucionar, con una buena práctica de prueba: encuentre maneras de mantener su conjunto de pruebas rápido (incluso si tiene que hacer trucos como distribuir ejecuciones de prueba en máquinas / CPU). Del mismo modo, se puede tener cuidado al tratar de evitar métodos frágiles para escribir pruebas.
fuente
Quiero agregar uno más, una falsa sensación de seguridad.
Más allá de conjuntos de problemas muy pequeños y bien definidos, no es posible crear pruebas exhaustivas. Puede haber, y con frecuencia habrá, errores en nuestro software que las pruebas automatizadas simplemente no prueban. Cuando pasan las pruebas automatizadas, con demasiada frecuencia asumimos que no hay errores en el código.
fuente
Es difícil convencer a la gerencia / capitalista de riesgo
ver Pruebas de unidades dirigidas por el mercado para más detalles.
fuente
Una de las principales desventajas puede superarse mediante el uso de pruebas de autoaprendizaje. En esta situación, todos los resultados esperados se almacenan como datos y se pueden actualizar con una revisión mínima por parte del usuario del conjunto de pruebas en modo de autoaprendizaje (mostrar diferencias entre el resultado esperado anterior y el resultado real nuevo; actualización esperada si se presiona y). Este modo de aprendizaje de prueba debe usarse con precaución para que no se aprenda el comportamiento defectuoso como aceptable.
fuente