¿Cuáles son las desventajas de las pruebas automatizadas?

Claramente has clavado los más importantes. Tengo algunas adiciones menores, más la desventaja de que las pruebas realmente tengan éxito, cuando en realidad no quieres que lo hagan (ver más abajo).

• Tiempo de desarrollo: con el desarrollo impulsado por pruebas, esto ya se calcula para pruebas unitarias, pero aún necesita pruebas de integración y de sistema, que también pueden necesitar un 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 deben ser compatibles. Pero no es solo tu propio equipo. En un proyecto más grande, puede tener un equipo de pruebas independiente que escribe pruebas para verificar las interfaces entre el producto de su equipo y el de otros. Muchas más personas tienen que tener más conocimientos.

• Necesidades de herramientas: tienes un lugar allí. No hay mucho que agregar a esto.

• Pruebas fallidas: este es el verdadero bugger (para mí de todos modos). Hay un montón de 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.

  • falló, debido a un error real. (solo para completar, ya que esto es ventajoso, por supuesto)
  • falló, porque su código de prueba se ha escrito con un error tradicional.
  • falló, porque su código de prueba se ha escrito para una versión anterior de su producto y ya no es compatible
  • falló, porque los requisitos han cambiado y el comportamiento probado ahora se considera "correcto"

• Pruebas no fallidas: estas también son una desventaja y pueden ser bastante malas. Ocurre principalmente, cuando cambias las cosas y se acerca a lo que Adam respondió. Si cambia algo en el código de su producto, pero la prueba no lo tiene en cuenta, 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 debe 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 en realidad verifica que su producto funciona incorrectamente . En algún lugar del camino, esto te afectará ... generalmente cuando / donde menos te lo esperas.

• Costos adicionales de implementación: no solo ejecuta pruebas unitarias como desarrollador en su propia máquina. Con las pruebas automatizadas, desea ejecutarlas en las 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.

Tras haber empezado a probar las pruebas automatizadas en nuestro equipo, la mayor desventaja que he visto es que es muy difícil aplicar a un código heredado que no fue diseñado teniendo en cuenta las pruebas automatizadas. Sin duda, mejoraría nuestro código a largo plazo, pero el nivel de refactorización necesario para las pruebas automatizadas, al tiempo que conserva nuestra cordura, es una barrera muy alta para el ingreso en el corto plazo, lo que significa que tendremos que ser muy selectivos con la introducción automática. 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 tiene una deuda técnica profunda.

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 necesita mantenimiento y soporte. Si no lo haces, obtendrás pruebas de las que no crees los resultados, por lo que no tienes otra opción. No me malinterpretes, soy un gran defensor de las pruebas automatizadas. Pero todo tiene un costo, y este es uno grande.

No diría que estas son desventajas totalmente aplicables, pero las pocas a las que más acierto son:

• Tiempo necesario para configurar la prueba en una aplicación empresarial compleja.
• El manejo de pruebas antiguas que fallan incorrectamente, en otras palabras, el sistema ha evolucionado y ahora las pruebas son incorrectas.
• Falsa confianza de la cobertura de prueba parcheada o desconocida.

La cobertura de prueba que es irregular puede llevar a una falsa sensación de seguridad. Si haces un refactor y usas las pruebas para demostrar su validez, ¿qué ha demostrado que tus pruebas pueden demostrar esto?

El tiempo que lleva crear la prueba a veces es un problema para nosotros. Nuestras pruebas automatizadas no solo incluyen pruebas unitarias, sino también pruebas de casos de uso. Estos tienden a ser más amplios y requieren contexto.

Por supuesto, mi perspectiva es desde una aplicación que es más antigua que sus pruebas unitarias.

Yo diría que el principal problema con ellos es que pueden proporcionar un falso sentido de seguridad . El hecho de que tenga pruebas de unidad no significa que en realidad sean haciendo nada y eso incluye probar adecuadamente los requisitos.

Además, las pruebas automatizadas también pueden incluir errores por sí mismas , por lo que la pregunta sobre si las pruebas unitarias necesitan probarse a sí mismas , por lo que no necesariamente se logra nada.

Aunque las pruebas de automatización tienen muchas ventajas, también tiene sus propias desventajas. Algunas de las desventajas son:

• Se requiere dominio para escribir los scripts de prueba de automatización.
• La depuración de la secuencia de comandos de prueba es un problema importante. Si algún error está presente en el script de prueba, a veces puede llevar a consecuencias mortales.
• El mantenimiento de la prueba es costoso en el caso de los métodos de reproducción. A pesar de que se produce un cambio menor en la GUI, el script de prueba debe ser regrabado o reemplazado por un nuevo script de prueba.
• El mantenimiento de los archivos de datos de prueba es difícil, si el script de prueba prueba más pantallas.

Algunas de las desventajas anteriores a menudo se restan del beneficio obtenido de los scripts automatizados. Aunque las pruebas de automatización tienen ventajas y ventajas, están adaptadas en todo el mundo.

Hace poco le pregunté a una pregunta sobre las pruebas en el desarrollo del juego - Esto es por cierto como supe de esto. Las respuestas apuntaban algunos inconvenientes curiosos y específicos:

1. Es costoso hacerlo cuando su código debería estar altamente acoplado .
2. Es difícil hacerlo cuando tiene que estar al tanto de las distintas plataformas de hardware, cuando debe analizar la salida al usuario y el código el resultado solo tiene sentido en un contexto más amplio .
3. La prueba de UI y UX es muy difícil .
4. Y, en particular, las pruebas automatizadas pueden ser más costosas y menos efectivas que un montón de probadores beta de muy bajo costo (o gratis) .

El cuarto punto me hace recordar alguna experiencia mía. Trabajé en una compañía muy pobre, orientada a XP y administrada por Scrum, donde las pruebas de unidad fueron altamente recomendadas. Sin embargo, en su camino hacia un estilo más esbelto y menos burocrático, la compañía simplemente descuidó la construcción de un equipo de control de calidad: no teníamos evaluadores. Muy a menudo, los clientes encontraron errores triviales en algunos sistemas, incluso con una cobertura de prueba de > 95%. Así que añadiría otro punto:

• Las pruebas automatizadas pueden hacerle sentir que el control de calidad y las pruebas no son importantes.

También, pensaba esos días en la documentación y pensé en una hipótesis que puede ser válida (en menor medida) para las pruebas dos. Simplemente sentí que el código evoluciona tan rápidamente que es bastante difícil hacer una documentación que siga esa velocidad, por lo que es más valioso dedicar tiempo a hacer que el código sea legible que escribir una documentación pesada y fácilmente desactualizada. (Por supuesto, este no se aplica a las API, sino solo a la implementación interna). La prueba tiene un poco el mismo problema: puede ser demasiado lenta para escribir cuando se compara 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 y cuando no la vuelva a leer muy, muy cuidadosamente .

Finalmente, un problema que encuentro a veces: las pruebas automatizadas pueden depender de las herramientas y esas herramientas pueden estar mal escritas. Comencé un proyecto con XUL hace algún tiempo y, hombre, esto es simplemente doloroso para escribir pruebas unitarias para dicha plataforma. Comencé con otra aplicación utilizando Objective-C, Cocoa y Xcode 3 y el modelo de prueba fue 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 firme defensor de las pruebas automatizadas. Esto ahorró mucho trabajo y dolores de cabeza y siempre lo recomiendo de forma predeterminada. Juzgo que esas desventajas son solo meros detalles en comparación con los beneficios de las pruebas automatizadas. (Es importante siempre proclamar su fe después de comentar herejías para evitar el auto da fé).

Dos que no se mencionan son:

• La duración del tiempo de reloj que puede llevar ejecutar un conjunto de pruebas grande

Formé parte de los esfuerzos de control de calidad automatizados en los que tardé medio día en realizar 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ás administrando ese tiempo, "Oh, acabo de comprometerme con una solución, pero tomará 4 horas demostrar la exactitud".

• Fragilidad de algunos métodos de escritura de prueba

Algunos métodos de prueba (como la automatización de la interfaz de usuario) parecen fallar cada vez que te das la vuelta. Especialmente doloroso si su secuencia de comandos, por ejemplo, bloquea el proceso de prueba porque está esperando que aparezca un botón, pero el nombre del botón se ha cambiado.

Estas son dos cosas con las que puede trabajar, con una buena práctica de prueba: encuentre formas de mantener su conjunto de pruebas rápido (incluso si tiene que hacer trucos como distribuir pruebas de ejecución entre máquinas / CPU). Del mismo modo, se puede tener cuidado al tratar de evitar métodos delicados de escribir pruebas.

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 completas. Puede que haya, y con frecuencia, haya 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.

Es difícil convencer a la gerencia / capitalista de riesgo

• la certificación aumenta los costos iniciales.
• la organización aumenta el tiempo de comercialización.
• el beneficio de la automatización viene en medio y largo plazo. la competencia feroz se centra más en los beneficios a corto plazo.

vea Pruebas de unidades impulsadas por el mercado para obtener más información.

Una de las principales desventajas se puede superar mediante el uso de pruebas de autoaprendizaje. En esta situación, los resultados esperados se almacenan todos como datos y se pueden actualizar con una revisión mínima por parte del usuario de la suite de prueba en modo de autoaprendizaje (mostrar diferencias entre el resultado esperado anterior y el nuevo resultado real: actualización esperada si se presiona y). Este modo de aprendizaje de prueba debe usarse con precaución para que el comportamiento de buggy no se aprenda como aceptable.