¿Cuándo las pruebas de unidad son inapropiadas o innecesarias? [duplicar]

Personalmente no escribiré pruebas unitarias para situaciones en las que:

1. El código no tiene sucursales es trivial. Un captador que devuelve 0 no necesita ser probado, y los cambios serán cubiertos por las pruebas para sus consumidores.

2. El código simplemente pasa a través de una API estable. Asumiré que la biblioteca estándar funciona correctamente.

3. El código debe interactuar con otros sistemas implementados; entonces se requiere una prueba de integración.

4. Si la prueba de éxito / fracaso es algo que es tan difícil de cuantificar como para no ser medible de manera confiable, como la esteganografía es imperceptible para los humanos.

5. Si la prueba en sí es un orden de magnitud más difícil de escribir que el código.

6. Si el código es desechable o código de marcador de posición. Si hay alguna duda, prueba.

A menos que escriba un código sin probarlo, siempre incurrirá en el costo de la prueba.

La diferencia entre tener pruebas unitarias y no tenerlas es la diferencia entre el costo de escribir la prueba y el costo de ejecutarla en comparación con el costo de la prueba a mano.

Si el costo de escribir una prueba unitaria es de 2 minutos y el costo de la ejecución de la prueba unitaria es prácticamente 0, pero el costo de la prueba manual del código es de 1 minuto, entonces usted gana el equilibrio cuando ha ejecutado la prueba dos veces.

Durante muchos años tuve la mala interpretación de que no tenía tiempo suficiente para escribir pruebas unitarias para mi código. Cuando escribí las pruebas, estaban hinchadas, cosas pesadas que solo me animaban a pensar que solo debería escribir pruebas de unidad cuando sabía que eran necesarias.

Recientemente me animaron a usar Development Driven Development y me pareció una revelación completa. Ahora estoy firmemente convencido de que no tengo el tiempo not para escribir pruebas unitarias.

En mi experiencia, al desarrollar teniendo en cuenta las pruebas, terminas con interfaces más limpias, clases más centradas y amp; módulos y en general más SOLID , código verificable.

Cada vez que trabajo con un código heredado que no tiene pruebas de unidad y tengo que probar algo manualmente, sigo pensando que "esto sería mucho más rápido si este código ya tuviera pruebas de unidad". Cada vez que tengo que intentar agregar una funcionalidad de prueba unitaria a un código con alto acoplamiento, sigo pensando que "esto sería mucho más fácil si se hubiera escrito de una manera desacoplada".

Comparando y contrastando las dos estaciones experimentales que apoyo. Uno ha existido por un tiempo y tiene una gran cantidad de códigos heredados, mientras que el otro es relativamente nuevo.

Al agregar funcionalidad al antiguo laboratorio, a menudo se trata de ir al laboratorio y pasar muchas horas trabajando en las implicaciones de la funcionalidad que necesitan y cómo puedo agregar esa funcionalidad sin afectar ninguna de las otras funciones. El código simplemente no está configurado para permitir pruebas fuera de línea, por lo que prácticamente todo tiene que desarrollarse en línea. Si intentara desarrollar fuera de línea, terminaría con más objetos simulados de lo que sería razonable.

En el laboratorio más nuevo, por lo general puedo agregar funcionalidad al desarrollarlo fuera de línea en mi escritorio, burlándome solo de las cosas que se requieren de inmediato, y luego pasar solo un corto tiempo en el laboratorio, resolviendo los problemas pendientes, no recogido fuera de línea.

TL; DR versión:

Escriba una prueba cuando el costo de escribir la prueba, más el costo de ejecutarla tantas veces como sea necesario, es probable que sea menor que el costo de realizar la prueba manualmente tantas veces como sea necesario.

Sin embargo, recuerde que si usa TDD, es probable que el costo de escribir las pruebas disminuya a medida que mejore, y a menos que el código sea absolutamente trivial, es probable que termine ejecutando las pruebas con más frecuencia de la que espera.

Personalmente, generalmente no escribo pruebas unitarias para:

• Cambios en el código existente no comprobado por unidades (legado). Si bien en teoría nunca es demasiado tarde para comenzar las pruebas unitarias, en la práctica las ventajas de agregar pruebas unitarias al código que nunca fue TDDed son pequeños. La única ventaja es la prevención de la regresión; puede ver qué efecto produce un cambio en las áreas que puede o no haber esperado que afecten. Sin embargo, la prueba de unidad solo prueba que el código aún funciona como lo hizo cuando escribió la prueba; Debido a que la prueba no se escribió en base a los requisitos originales, la prueba no prueba que la implementación actual sea "correcta". Hacer cambios probados por la unidad en tal base de código es aún más una pesadilla en mi experiencia que simplemente hacer el cambio y ejercitar manualmente las áreas afectadas del programa; primero tiene que escribir una prueba de unidad adecuada para el código en cuestión (que puede requerir una refactorización del código para permitir la burla y otra arquitectura compatible con TDD), probar que pasa y que el refactor no rompió nada (y cuando esto ocurre) la primera prueba de unidad escrita para un código de millones de LoC, que puede ser difícil), luego cambie la prueba para esperar algo diferente y cambie el código para hacer que se apruebe la prueba cambiada.

• Diseño de interfaz de usuario y comportamiento de nivel superior . En algunos casos simplemente no es factible; muchos IDE con "diseñadores" declaran los elementos de la interfaz de usuario como privados, y no deberían ser públicos conceptualmente. Hacerlos internos requeriría colocar las pruebas unitarias en los mismos ensamblajes que el código de producción (incorrecto) y hacerlos protegidos requeriría un "proxy de prueba" que expone lo que necesitamos saber sobre los controles (en general, no de la forma en que se hacen). Incluso si fuera aceptable hacer públicos todos los controles y así tener acceso a su tipo, posición, propiedades de formato, etc., las pruebas que verifican que la interfaz de usuario está diseñada de la manera que usted espera son extremadamente frágiles. Por lo general, aún puede probar los controladores de eventos de unidad en codebehinds / viewmodels y luego es trivial probar que hacer clic en el botón activa el controlador.

• Persistencia en la base de datos . Esto es, por definición, una prueba de integración. Siempre se burla del repositorio cuando se trata de código que pasa datos al repositorio, y se burla de los ganchos de ORM cuando se desarrolla dentro del repositorio en sí. Si bien hay "pruebas de unidad de base de datos" y se puede "simular" una base de datos utilizando algo como SQLite, me parece que estas pruebas nunca se ajustan al nivel de la unidad.

• Código de terceros . Usted prueba SU código como desee, y confía en que los desarrolladores de las herramientas de terceros que está utilizando (incluidos los componentes de .NET Framework como WPF, WCF, EF, etc.) hicieron su trabajo correctamente, hasta que se comprobó que estaban equivocados. Una prueba de unidad que prueba que usted realiza la llamada correcta de WCF no requiere que realmente se cruce el proxy de servicio, y no es necesario probar que una llamada de servicio WCF particular funciona correctamente en una prueba de unidad (si funciona o no). no depende de las variables específicas del entorno que pueden ser perfectas en un entorno de prueba local pero no en el build-bot, o en los entornos de control de calidad, estadificación o UAT; aquí es donde la integración de nivel superior, AAT y las pruebas manuales aún tienen valor) .

En casi todos los otros casos, una metodología de primera prueba tiene un valor significativo en el cumplimiento de los requisitos y el YAGNI, previene la regresión, identifica conflictos de requisitos, etc. Incluso en casos de código "trivial", esa verificación indica que "sí, esta propiedad sí aún así, devuelva este valor y, por lo tanto, puede confiar en que en otras pruebas "tiene valor para mí como desarrollador.

Existe un compromiso entre el costo de escribir las pruebas unitarias y el valor que agregan. Si no lo hace, se arriesga a la posibilidad de sobrepruebas .

blueberryfields tocó una variable que afecta el valor de las pruebas unitarias: la estabilidad del proyecto (o el ritmo de desarrollo). Me gustaría ampliar eso.

El valor de tener pruebas unitarias sigue aproximadamente la siguiente gráfica (yay, MS Paint!):

1. Enlaprimerazona,elcódigoesinestablehastaelpuntodequelaspruebasunitariasamenudotendránquereescribirseoeliminarseporcompleto.Estopodríaserunprototipoquesabesquenoseutilizará.Opodríaserunproyectoenelqueeresnuevoenellenguajedeprogramaciónoelmarco(y,amenudo,esnecesariorehacergrandescantidadesdecódigo).

   Laspruebasunitariassonbuenaspararefactorizaraniveldemódulo(esdecir,paracambiarfunciones).Elproblemaescuandoelcódigoesinestableenelnivelarquitectónico,dondesepuedenreescribir,eliminarorediseñarcompletamentemóduloscompletos.Laspruebasdelaunidadluegosedebencambiar/eliminar/agregar,locualesunacarga.

   Enestaetapa,limitarsealaspruebasdeintegraciónaniveldelsistema,oinclusoalaspruebasmanualesesunmejorenfoque(elqueelijanuevamentedependerádelcostodeescribirlapruebaencomparaciónconelvalorqueobtenga).

2. Laspruebasunitariasagreganelmayorvalorenlasegundazona,dondeelcódigosevuelveestablearribadelniveldelmódulo,peroaúnnoestáenelniveldelmódulo.Sitieneunabasedecódigoestableyestáagregandounmóduloquetieneunaaltaprobabilidaddequedarse,estoescuandolapruebadeunidadesunagranganancia.

3. Laspruebasunitariastambiéncomienzanatenermenosvalorcuandolaestabilidaddelcódigobajopruebaesmuyalta.Probarunenvoltoriosimpledeunafuncióndebibliotecaestándaresunejemploenelquelaspruebasunitariassonexcesivas.

   Siunfragmentodecódigoqueestáescribiendonuncatendráquecambiar,yconfíaenquelohayahechobien(¿quizásseasupersimple?),haymenosvalorparalaspruebas.

Lapruebadelaunidadsevuelvebeneficiosacuandolautilidadesmayorqueelcosto,comosemuestraenelsiguientegráficoenlazonaII.

Esta línea de costo podría estar en diferentes niveles para diferentes personas (línea 1 frente a línea 2). Si es nuevo en el marco de prueba utilizado en un proyecto, esto aumenta el nivel y hace que la utilidad net sea menor. Un costo más alto (línea 2) reduce el rango que la prueba de unidad es apropiada.

La línea de costos no necesariamente tiene que ser plana. Especialmente cuando considera otras variables como el tamaño del proyecto y si ya existe un marco de prueba para el proyecto, esto podría ser así.

  

¿Dónde son menos valiosas las pruebas unitarias?

Debería estar escribiendo pruebas unitarias solo para el código lógico. La definición de código lógico está abajo:

El código lógico es cualquier pieza de código que tiene algún tipo de lógica, pequeño como puede ser. Es un código lógico si tiene uno o más de los siguiente: una declaración IF, un bucle, un conmutador o declaraciones de caso, cálculos, o cualquier otro tipo de código de toma de decisiones.

  

Si ese es el final del espectro donde la prueba de unidad es más valiosa,   entonces cual es el otro extremo?

• El código estrechamente acoplado no se puede probar fácilmente. A veces no puede ser probado en absoluto. Por ejemplo, los formularios web ASP.NET son una pesadilla y, a veces, imposibles de probar, a diferencia de ASP.NET MVC que se crea teniendo en cuenta las pruebas unitarias.

• Puedo elegir no escribir pruebas para proyectos muy pequeños y simples. Esto es perfectamente justificable en un mundo con tiempo y recursos limitados. Sí, es arriesgado, pero es perfectamente aceptable cuando la empresa para la que trabaja tiene un tiempo limitado de comercialización.

  

¿Qué situaciones no te molestaría? ¿Dónde estaría el esfuerzo de   ¿Mantener las pruebas no valdrá la pena?

Una vez que se realizan las pruebas unitarias, su costo de mantenimiento se vuelve muy insignificante. Las pruebas unitarias con alta cobertura de código le dan una valiosa sensación de confianza de que el sistema se comporta de la manera que usted espera. Lo mismo se aplica a las pruebas de integración, pero esa no es tu pregunta.

Mi respuesta se basa en los siguientes supuestos:

• Usted sabe la diferencia entre pruebas de unidad, integración y funcionales.
• Eres competente con uno de los marcos de prueba de unidad, y te toma muy poco esfuerzo escribir una prueba de unidad.
• No te sientes como si estuvieras haciendo un trabajo extra cuando estás escribiendo pruebas unitarias.

Referencia: Art of Unit Testing

Kent Beck (el hombre detrás de la idea de Pruebas unitarias) dice que está bien no escribir Pruebas unitarias cuando se trabaja en una idea (por ejemplo, un prototipo) que puede deshacerse (si decide no hacerlo). trabajar más adelante). Por el contrario, si escribe su prototipo y decide hacerlo, Unit Testing será útil por todas las razones cubiertas en las respuestas anteriores.

Realmente deberías tener pruebas para cualquier código que quieras ejecutar en más de una ocasión.

Si tiene la intención de ejecutarlo una vez, deséchelo, las pruebas pueden no ser útiles, aunque si el dominio es complejo, podría escribir las pruebas de todos modos para ayudarme con mi diseño e implementación.

De lo contrario, incluso si lo único que hacen las pruebas es confirmar que sus suposiciones siguen siendo correctas, son valiosas. Y cualquier código que dure más de una sesión necesitará modificaciones, momento en el cual las pruebas se pagarán por sí mismas 10 veces más.

No tengo idea de que sea innecesario , pero lo haré cuando crea que las Pruebas de unidad son inapropiadas , ya que agregan costo sin un beneficio proporcional:

Si nuestro equipo de organización / desarrollo no está realizando ninguna prueba unitaria, entonces, a menos que pueda convencer a sus compañeros desarrolladores de ejecutar, corregir (y también crear por su cuenta) las pruebas unitarias, las pruebas que cree no irán para ser ejecutado y mantenido. (Esto implica que está trabajando en una pieza de software junto con otra persona).

No todos están haciendo pruebas unitarias, a veces están mal apoyados por la cultura del equipo local, y en tales entornos primero necesitas ponerlos en su lugar para la mayoría de los desarrolladores y probablemente también para el proceso de compilación ("[continua ] integración ") antes de comenzar realmente a escribir pruebas unitarias tiene sentido.

Dada la presión de tiempo y las fechas de entrega y "su" pariente en el equipo, el tiempo restante hasta que las pruebas de unidad de escritura tengan sentido pueden ser fácilmente meses o años.

A veces no tienes tiempo para la prueba de unidad. Eso está bien.

Existen restricciones externas y es posible que no sienta la necesidad de realizar pruebas en un momento dado, ya que puede pensar que tiene un buen dominio de todo el estado del sistema y sabe cómo se producirán los cambios.

Pero sigo creyendo que deberías sentirte un poco culpable por ello. Entonces, cuando las cosas empiecen a desmoronarse, sabrás que es porque: "oh, sí, no estoy probando cosas, empecemos a probar".

Antes de ese momento, la sensación de culpa lo ayudará a evitar ciertas opciones arquitectónicas que le impedirían poder automatizar las pruebas de código más adelante.

El costo no se basa en mantener las pruebas, sino en no mantener el código de trabajo. Si se divorcia de las pruebas y la implementación, está asumiendo que lo que escriba funcionará sin el beneficio de la prueba. Las pruebas le dan esa prueba y la confianza para mantener el código a medida que pasa el tiempo. Seguro que puedes pensar que nunca volverás a visitar esa aplicación que pensabas que era una basura, sin embargo, la realidad es que cada vez que gastas escribiendo software es una inversión que tu empleador no quiere tratar a la ligera. Seamos realistas, los desarrolladores de software generalmente no son baratos, y el tiempo empleado en el código para deshacerse de ellos es dinero que simplemente se quema para su empleador.

Si está detectando un problema, escribiendo algunas líneas de código para ver cómo funciona algo, o simplemente lanzando un ejemplo para Programmers.SE, es realmente un caso de crear algo que tiene la intención de deshacerse de él una vez que He satisfecho su comprensión de un problema. En tales casos, las pruebas unitarias pueden ser un obstáculo para la tarea y pueden omitirse con seguridad. Sin embargo, en todos los demás casos, diría que las pruebas siempre son apropiadas, incluso si el programa parece relativamente poco importante, y siempre debe tratar de escribir un software a un estándar profesional con suficiente soporte de pruebas para reducir la dificultad de mantener el código en el futuro.

La cantidad y calidad de las pruebas de unidad que se realizarán en un proyecto es directamente proporcional al ritmo de desarrollo y la estabilidad requerida del producto.

En un extremo, para una secuencia de comandos única, una demostración trivial o en un entorno de inicio rápido durante las primeras etapas, es poco probable que las pruebas unitarias importen o sean útiles para cualquier cosa. Casi siempre son, casi con toda seguridad, una pérdida de tiempo y recursos.

En el otro extremo, al escribir software para controlar marcapasos, o cohetes piloto, o al trabajar para mantener sistemas de software estables y altamente complejos (por ejemplo, un compilador con una gran adopción en todo el multiverso) varias capas de unidades prueba, y otra cobertura, son cruciales.

[Hay muchos otros factores específicos de situaciones en los que cada uno contribuye de una manera u otra, como el tamaño de su equipo, su presupuesto, el talento de sus desarrolladores, su estrategia de desarrollo de software preferida, etc. En general, y en el nivel más alto de abstracción, encuentro que estos dos hacen la mayor diferencia]

En mi opinión, los prototipos de producto / código no requieren pruebas, ya que a menudo se entregan mediante un proceso completamente diferente y para propósitos completamente diferentes a los de un producto terminado.

Imagina este escenario común. Tiene algún tipo de tecnología por la que su empresa es famosa, su equipo de ventas o un jefe ejecutivo se dirige a un cliente y puede venderle un producto diferente que está aprovechando su tecnología. Lo venden allí y luego, y prometen al cliente que verán una versión beta dentro de un mes. No tienes nada, ni siquiera un equipo de desarrollo.

Lo que sucede a continuación es que usted diseña rápidamente una solución basada en los puntos acordados / vendidos al cliente, reúne un equipo de ingenieros (a menudo estrella) y comienza a escribir el código. Sería ideal, por supuesto, si sus fechas no se deslizaran (siempre lo hacen) y usted logró escribir el código dentro de tres semanas en lugar de cuatro. En este caso, tiene una semana adicional, y si pudo asegurar el tiempo de un equipo de control de calidad para esta semana, lo probará. En realidad, no tendrá una semana adicional y / o su equipo de control de calidad estará reservado por otros dos meses para respaldar la entrega de otros productos. Además, no tendrá ninguna especificación de diseño, por lo que el equipo de control de calidad no tendrá idea de lo que se supone que deben probar. Así que terminas entregando lo que escribiste con un poco de tus propias pruebas de humo, lo cual no es realmente una prueba como tal, simplemente porque no estás calificado para probar tu propio código. El factor más importante aquí es que el cliente verá algunas de las funciones prometidas muy rápidamente. Si su prototipo hace el trabajo, entonces volverá al tablero de dibujo, donde diseñará y planificará la versión 1.0 real, correctamente esta vez.

En cuanto a las pruebas unitarias, son buenas para mantener ciertos contratos (prometo que mi código hará esto, si no lo hace, está roto). En el caso de los prototipos, es posible que no le interesen tanto los contratos, porque con la suficiente frecuencia sus prototipos no se convertirán en la versión 1.0, ya sea porque el cliente se fue o porque usted terminó desarrollando su versión 1.0 con diferentes tecnologías / herramientas. Un ejemplo aquí sería un sitio web de prototipo rápido escrito muy rápidamente en PHP dentro de un mes por una persona, y luego se reúne un equipo para reescribirlo en JEE. Incluso la base de datos a menudo no sobrevivirá a este cambio.

Debe escribir pruebas unitarias cuando la comprensión lógica requerida para mantener o extender o comunicar la lógica de la aplicación sin fallas exceda (o probablemente lo haga en el futuro) la capacidad del miembro con menos conocimientos de su equipo para cumplir con eso comprensión.

Básicamente depende de cuánto puedes mantener en tu cabeza al mismo tiempo. Por su cuenta, es posible que tenga más confianza en que puede codificar (con pleno conocimiento del impacto de sus cambios) hasta que se haya alcanzado una cierta complejidad. Hasta ese momento, las pruebas unitarias son una distracción, un obstáculo y te harán más lento. En un equipo, el umbral será mucho más bajo, por lo que prácticamente necesitas pruebas de unidad de inmediato para contrarrestar la estupidez del grupo. Si selecciona un proyecto sin prueba de otra persona (o si se ha olvidado de un proyecto de hace un tiempo), querrá escribir pruebas de unidad antes de cambiar algo porque su comprensión será cero.

Nota: escribir menos código y practicar YAGNI, mantiene baja la complejidad y, por lo tanto, el número de pruebas de unidades requeridas.

Las pruebas unitarias son agradables y todo, pero en sistemas complicados con muchas "partes móviles", realmente no prueban mucho.

Como sabemos, las pruebas unitarias aseguran que, dada la entrada X para una unidad, obtengas una salida Y donde X es toda la entrada apropiada e Y es toda la salida apropiada. Sin embargo, me parece que la mayoría del código hace lo que el desarrollador pensó que debería ... pero no es necesario lo que realmente debería hacer.
(Podría pensarlo como una pistola. Una pistola tiene un montón de piezas de precisión fabricadas por separado y luego ensambladas. No importa si cada pieza en particular tiene buenas pruebas de funcionalidad si la pistola explota cuando se dispara realmente. Exención de responsabilidad : No sé nada de armas de fuego (:)

En estos casos, necesitamos pruebas reales del sistema en un entorno de producción modelo. Como la funcionalidad se prueba aquí de todos modos, el valor de las pruebas unitarias disminuye ligeramente.

Sin embargo, las pruebas unitarias siguen siendo valiosas en este caso porque brindan la seguridad de que la funcionalidad que usted desea que permanezca sin cambios, de hecho, permanece sin cambios. Esto es bastante valioso porque le da confianza para las áreas donde el sistema necesita pruebas enfocadas.

Las pruebas unitarias de la OMI son inapropiadas (¡no son innecesarias!) en cualquier base de código donde requeriría toneladas de horas de refactorización o incluso una reescritura completa para introducir pruebas unitarias, ya que sería una venta muy difícil para la administración permitir esa asignación de tiempo.

En una organización más pequeña y de ritmo rápido, encuentro que los desarrolladores están tan presionados para mantenerse productivos y moverse con rapidez, que a menudo simplemente no se molestan en probar sus propios cambios.

Tenemos una política general que establece que si realiza un cambio (ya sea una corrección de errores o una mejora), el desarrollador debe probarlo por sí mismo antes de enviar el código para una mayor garantía de calidad.

En realidad, no escribimos pruebas unitarias para la mayoría de los casos porque nuestras pantallas están diseñadas en su mayoría de manera que si se realiza un cambio en la pantalla, el resto de la lógica debe atravesarse para averiguar si el el cambio fue exitoso a pesar de todo.

Me parece imperativo que el desarrollador haga sus propias pruebas, ya sea que esté documentado o no, porque son los que mejor saben dónde están los posibles puntos débiles de la lógica.

Por lo tanto, diría que, incluso si no escribe pruebas unitarias para cada pequeña parte del sistema, las pruebas de sentido común deberían realizarse independientemente.