tdd - test - ¿Cómo pruebas tu unidad una prueba unitaria?
pruebas unitarias php (17)
Estaba viendo webcasts de Rob Connerys en la aplicación MVCStoreFront, y me di cuenta de que estaba probando unidades incluso las cosas más mundanas, como:
public Decimal DiscountPrice
{
get
{
return this.Price - this.Discount;
}
}
Tendría una prueba como:
[TestMethod]
public void Test_DiscountPrice
{
Product p = new Product();
p.Price = 100;
p.Discount = 20;
Assert.IsEqual(p.DiscountPrice,80);
}
Si bien, estoy a favor de las pruebas unitarias, a veces me pregunto si esta forma de primer desarrollo de prueba es realmente beneficiosa, por ejemplo, en un proceso real, tiene 3-4 capas por encima de su código (solicitud comercial, documento de requisitos, documento de arquitectura) , donde la regla comercial definida real (precio de descuento es precio - descuento) podría estar mal definida.
Si esa es la situación, la prueba de su unidad no significa nada para usted.
Además, su prueba de unidad es otro punto de falla:
[TestMethod]
public void Test_DiscountPrice
{
Product p = new Product();
p.Price = 100;
p.Discount = 20;
Assert.IsEqual(p.DiscountPrice,90);
}
Ahora la prueba es defectuosa Obviamente, en una prueba simple, no es gran cosa, pero digamos que estábamos probando una regla empresarial complicada. ¿Qué ganamos aquí?
Avanzamos rápidamente dos años en la vida de la aplicación, cuando los desarrolladores de mantenimiento la mantienen. Ahora el negocio cambia su regla, y la prueba se rompe nuevamente, algún desarrollador novato luego corrige la prueba incorrectamente ... ahora tenemos otro punto de falla.
Todo lo que veo es más posibles puntos de falla, sin retorno real beneficioso; si el precio de descuento es incorrecto, el equipo de prueba aún encontrará el problema, ¿cómo evitó la prueba unitaria?
¿Que me estoy perdiendo aqui? Por favor enséñame a amar a TDD, ya que estoy teniendo dificultades para aceptarlo como útil hasta ahora. Yo también quiero, porque quiero seguir siendo progresivo, pero simplemente no tiene sentido para mí.
EDITAR: Un par de personas siguen mencionando que las pruebas ayudan a hacer cumplir las especificaciones. Según mi experiencia, la especificación también ha sido incorrecta, la mayoría de las veces, pero tal vez estoy condenado a trabajar en una organización donde las especificaciones están escritas por personas que no deberían escribir especificaciones.
Todo lo que veo es más posibles puntos de falla, sin retorno real beneficioso; si el precio de descuento es incorrecto, el equipo de prueba aún encontrará el problema, ¿cómo evitó la prueba unitaria?
Las pruebas unitarias realmente no se supone que para ahorrar trabajo, se supone que lo ayudarán a encontrar y prevenir errores. Es más trabajo, pero es el tipo correcto de trabajo. Está pensando en su código en los niveles más bajos de granularidad y escribiendo casos de prueba que prueban que funciona en las condiciones esperadas , para un conjunto dado de datos. Se trata de variables de aislamiento para que puedas ahorrar tiempo buscando en el lugar correcto cuando se presente un error. Está guardando ese conjunto de pruebas para que pueda usarlas una y otra vez cuando tenga que realizar un cambio en el futuro.
Personalmente creo que la mayoría de las metodologías no están a muchos pasos de la ingeniería de software de culto a la carga , TDD incluida, pero no es necesario adherirse a la TDD estricta para cosechar los beneficios de las pruebas unitarias. Mantenga las partes buenas y elimine las partes que rinden poco beneficio.
Finalmente, la respuesta a su pregunta principal " ¿Cómo se prueba una unidad una prueba de unidad? " Es que no debería tener que hacerlo. Cada prueba de unidad debe ser simple cerebro muerto. Llame a un método con una entrada específica y compárelo con su salida esperada. Si la especificación para un método cambia, entonces puede esperar que algunas de las pruebas unitarias para ese método también tengan que cambiar. Esa es una de las razones por las que realiza pruebas unitarias a un nivel tan bajo de granularidad, por lo que solo algunas de las pruebas de unidad deben cambiar. Si encuentra que las pruebas para muchos métodos diferentes están cambiando para un cambio en un requisito, entonces es posible que no esté probando a un nivel suficientemente fino de granularidad.
Si bien, estoy a favor de las pruebas unitarias, a veces me pregunto si esta forma de desarrollo de la primera prueba es realmente beneficiosa ...
Pruebas pequeñas y triviales como esta pueden ser el "canario en la mina de carbón" para su código base, alertando sobre el peligro antes de que sea demasiado tarde. Las pruebas triviales son útiles para mantener porque le ayudan a tener las interacciones correctas.
Por ejemplo, piense en una prueba trivial puesta en marcha para probar cómo usar una API con la que no está familiarizado. Si esa prueba tiene alguna relevancia para lo que está haciendo en el código que usa la API "de verdad", es útil mantener esa prueba. Cuando la API lanza una nueva versión y necesita actualizarse. Ahora tiene sus suposiciones sobre cómo espera que se comporte la API registrada en un formato ejecutable que puede usar para detectar regresiones.
... [I] En un proceso real, tiene de 3 a 4 capas por encima de su código (solicitud comercial, documento de requisitos, documento de arquitectura), donde la regla empresarial definida real (precio de descuento es precio - descuento) podría estar mal definida. Si esa es la situación, la prueba de su unidad no significa nada para usted.
Si ha estado codificando durante años sin escribir pruebas, puede no ser inmediatamente obvio para usted que hay algún valor. Pero si usted piensa que la mejor manera de trabajar es "liberar temprano, lanzar a menudo" o "agilizar", ya que desea la capacidad de implementar rápidamente / continuamente, entonces su prueba definitivamente significa algo. La única forma de hacerlo es legitimando cada cambio que realice en el código con una prueba. No importa cuán pequeña sea la prueba, una vez que tiene un banco de pruebas verde, teóricamente está bien para implementarlo. Ver también "producción continua" y "beta perpetua".
No es necesario que seas "el primero en probar" para tener esta mentalidad, pero esa es, por lo general, la forma más eficiente de llegar allí. Cuando haces TDD, te encerras en un pequeño ciclo de Refactor Rojo Verde de dos o tres minutos. En ningún momento no podrá detenerse, irse y tener un desorden total en sus manos que demorará una hora en depurarse y volverse a unir.
Además, su prueba de unidad es otro punto de falla ...
Una prueba exitosa es aquella que demuestra una falla en el sistema. Una prueba de falla lo alertará de un error en la lógica de la prueba o en la lógica de su sistema. El objetivo de tus pruebas es romper tu código o probar que un escenario funciona.
Si está escribiendo pruebas después del código, corre el riesgo de escribir una prueba que es "mala" porque para ver si su prueba realmente funciona, necesita verla rota y funcionando. Cuando estás escribiendo pruebas después del código, esto significa que tienes que "saltar la trampa" e introducir un error en el código para ver que la prueba falla. La mayoría de los desarrolladores no solo están incómodos con esto, sino que argumentan que es una pérdida de tiempo.
¿Qué ganamos aquí?
Definitivamente hay un beneficio para hacer las cosas de esta manera. Michael Feathers define el "código heredado" como "código no probado". Cuando adopta este enfoque, legitima todos los cambios que realice en su base de código. Es más riguroso que no usar pruebas, pero cuando se trata de mantener una gran base de código, se paga por sí mismo.
Hablando de Plumas, hay dos grandes recursos que debes consultar en relación con esto:
Ambas explican cómo trabajar este tipo de prácticas y disciplinas en proyectos que no son "Greenfield". Proporcionan técnicas para escribir pruebas sobre componentes estrechamente acoplados, dependencias de cable rígido y cosas sobre las que no necesariamente tiene control. Se trata de encontrar "costuras" y probarlas.
[Si] el precio de descuento es incorrecto, el equipo de prueba aún encontrará el problema, ¿cómo las pruebas unitarias guardaron algún trabajo?
Hábitos como estos son como una inversión. Las devoluciones no son inmediatas; se acumulan con el tiempo La alternativa para no hacer las pruebas es, en esencia, asumir la deuda de no poder detectar regresiones, introducir el código sin temor a errores de integración o tomar decisiones de diseño. La belleza es que legitimas todos los cambios introducidos en tu base de código.
¿Que me estoy perdiendo aqui? Por favor enséñame a amar a TDD, ya que estoy teniendo dificultades para aceptarlo como útil hasta ahora. Yo también quiero, porque quiero seguir siendo progresivo, pero simplemente no tiene sentido para mí.
Lo veo como una responsabilidad profesional. Es un ideal para luchar hacia. Pero es muy difícil de seguir y tedioso. Si te importa y crees que no debes producir un código que no se haya probado, podrás encontrar la fuerza de voluntad para aprender buenos hábitos de prueba. Una cosa que hago mucho ahora (al igual que otras) es el tiempo en que me tomo una hora escribir el código sin ninguna prueba, y luego tengo la disciplina para descartarlo. Esto puede parecer un desperdicio, pero no es realmente. No es que el ejercicio le haya costado a una empresa materiales físicos. Me ayudó a entender el problema y cómo escribir el código de tal manera que sea de mayor calidad y comprobable.
En última instancia, mi consejo sería que si realmente no desea ser bueno en eso, no lo haga en absoluto. Las pruebas deficientes que no se mantienen, no funcionan bien, etc. pueden ser peores que no tener ninguna prueba. Es difícil aprender por sí mismo, y probablemente no lo amarás, pero será casi imposible de aprender si no tienes ganas de hacerlo, o si no puedes ver suficiente valor para hacerlo. garantiza la inversión de tiempo.
Un par de personas siguen mencionando que las pruebas ayudan a hacer cumplir la especificación. Ha sido mi experiencia que la especificación ha sido incorrecta también, la mayoría de las veces ...
El teclado de un desarrollador es donde la goma se encuentra con la carretera. Si la especificación es incorrecta y no se levanta la bandera, es muy probable que te culpen por ello. O al menos tu código lo hará. La disciplina y el rigor que implican las pruebas es difícil de cumplir. No es para nada fácil. Requiere práctica, mucho aprendizaje y muchos errores. Pero finalmente vale la pena. En un proyecto vertiginoso que cambia rápidamente, es la única forma en que puede dormir por la noche, sin importar si eso le ralentiza.
Otra cosa en que pensar aquí es que las técnicas que son básicamente las mismas que las pruebas han demostrado funcionar en el pasado: "sala limpia" y "diseño por contrato" tienden a producir los mismos tipos de construcciones de código "meta" que hacer las pruebas, y aplicarlas en diferentes puntos. Ninguna de estas técnicas es una bala de plata, y el rigor le va a costar finalmente en el alcance de las características que puede ofrecer en términos de tiempo de comercialización. Pero de eso no se trata. Se trata de ser capaz de mantener lo que haces entregar. Y eso es muy importante para la mayoría de los proyectos.
¡Incluso más automatización puede ayudar aquí! Sí, las pruebas de unidad de escritura pueden requerir mucho trabajo, por lo tanto, use algunas herramientas para ayudarlo. Eche un vistazo a algo como Pex, de Microsoft, si está usando .Net. Automáticamente creará suites de pruebas de unidad para usted al examinar su código. Aparecerá con pruebas que ofrecen una buena cobertura, tratando de cubrir todas las rutas a través de tu código.
Por supuesto, con solo mirar su código no puede saber lo que en realidad está tratando de hacer, por lo que no sabe si es correcto o no. Sin embargo, generará casos de prueba interesantes para usted, y luego podrá examinarlos y ver si se comporta como espera.
Si luego vas más allá y escribes pruebas de unidades parametrizadas (puedes pensar en estos como contratos, realmente) generará casos de pruebas específicos a partir de ellas, y esta vez puede saber si algo está mal, porque tus afirmaciones en tus pruebas fallarán.
¿Cómo se prueba una prueba ? Las pruebas de mutaciones son una técnica valiosa que personalmente he usado para obtener un efecto sorprendentemente bueno. Lea el artículo vinculado para obtener más detalles, y enlaces a referencias académicas aún más, pero en general "prueba sus pruebas" modificando su código fuente (cambiando "x + = 1" por "x - = 1" por ejemplo) y luego volver a ejecutar sus pruebas, asegurando que al menos una prueba falla. Cualquier mutaciones que no causan fallas de prueba se marcan para una investigación posterior.
Se sorprendería de cómo puede tener una cobertura de línea y sucursal del 100% con un conjunto de pruebas que se ven completas y, sin embargo, fundamentalmente puede cambiar o incluso comentar una línea en su fuente sin que ninguna de las pruebas se queje. A menudo, esto se reduce a no probar con las entradas correctas para cubrir todos los casos límite, a veces es más sutil, pero en todos los casos quedé impresionado con lo mucho que salió de él.
Al aplicar Desarrollo controlado por prueba (TDD), uno comienza con una prueba de falla . Este paso, que podría parecer innecesario, en realidad está aquí para verificar que la prueba unitaria está probando algo. De hecho, si la prueba nunca falla, no aporta ningún valor y, lo que es peor, conduce a una confianza equivocada, ya que contará con un resultado positivo que no está probando nada.
Al seguir estrictamente este proceso, todas las "unidades" están protegidas por la red de seguridad que las pruebas de la unidad están haciendo, incluso las más mundanas.
Assert.IsEqual(p.DiscountPrice,90);
No hay ninguna razón para que la prueba evolucione en esa dirección, o me falta algo en su razonamiento. Cuando el precio es 100 y el descuento 20, el precio de descuento es 80. Esto es como un invariante.
Ahora imagina que tu software necesita soportar otro tipo de descuento basado en el porcentaje, quizás dependiendo del volumen comprado, tu método Product :: DiscountPrice () se vuelva más complicado. Y es posible que la introducción de esos cambios rompa la regla de descuento simple que teníamos inicialmente. Luego verá el valor de esta prueba que detectará la regresión de inmediato.
Rojo - Verde - Refactor - esto es para recordar la esencia del proceso TDD.
Rojo se refiere a la barra roja JUnit cuando falla una prueba.
El verde es el color de la barra de progreso JUnit cuando pasan todas las pruebas.
Refactor en condiciones verdes: elimine cualquier dupliación, mejore la legibilidad.
Ahora, para abordar su punto sobre las "3-4 capas sobre el código", esto es cierto en un proceso tradicional (similar a una cascada), no cuando el proceso de desarrollo es ágil. Y ágil es el mundo de donde viene TDD; TDD es la piedra angular de eXtreme Programming .
Agile tiene que ver con la comunicación directa en lugar de documentos de requisito arrojados sobre la pared.
En primer lugar, las pruebas son como seguridad: nunca puede estar 100% seguro de que lo tiene, pero cada capa agrega más confianza y un marco para solucionar más fácilmente los problemas que quedan.
En segundo lugar, puede dividir las pruebas en subrutinas que luego se pueden probar. Cuando tienes 20 pruebas similares, hacer una subrutina (probada) significa que tu prueba principal es 20 invocaciones simples de la subrutina que es mucho más probable que sea correcta.
En tercer lugar, algunos argumentarían que TDD aborda esta preocupación. Es decir, si solo escribes 20 pruebas y pasan, no estás completamente seguro de que realmente están probando algo. Pero si cada prueba que escribió inicialmente falló , y luego la solucionó, entonces tiene mucha más confianza de que realmente está probando su código. En mi humilde opinión, este ir y venir lleva más tiempo de lo que vale, pero es un proceso que intenta abordar su preocupación.
Es poco probable que una prueba errónea rompa su código de producción. Al menos, no es peor que no tener ninguna prueba en absoluto. Por lo tanto, no es un "punto de falla": las pruebas no tienen que ser correctas para que el producto realmente funcione. Es posible que tengan que ser correctos antes de que se firme como si estuvieran funcionando, pero el proceso de arreglar cualquier prueba rota no pone en peligro su código de implementación.
Puede pensar en pruebas, incluso pruebas triviales como estas, como una segunda opinión de lo que se supone que debe hacer el código. Una opinión es la prueba, la otra es la implementación. Si no están de acuerdo, entonces sabes que tienes un problema y miras más de cerca.
También es útil si alguien en el futuro quiere implementar la misma interfaz desde cero. No deberían tener que leer la primera implementación para saber lo que significa el descuento, y las pruebas actúan como una copia de seguridad inequívoca de cualquier descripción escrita de la interfaz que pueda tener.
Dicho esto, estás intercambiando tiempo. Si hay otras pruebas que podría estar escribiendo usando el tiempo que ahorra saltándose estas pruebas triviales, tal vez serían más valiosas. Depende de la configuración de la prueba y de la naturaleza de la aplicación, realmente. Si el descuento es importante para la aplicación, de todos modos, se detectarán errores en este método en las pruebas funcionales. Todas las pruebas de unidad lo hacen para detectarlas en el punto en el que está probando esta unidad, cuando la ubicación del error será inmediatamente obvia, en lugar de esperar hasta que la aplicación esté integrada y la ubicación del error sea menos obvia.
Por cierto, personalmente no usaría 100 como precio en el caso de prueba (o más bien, si lo hiciera, agregaría otra prueba con otro precio). La razón es que alguien en el futuro podría pensar que el descuento se supone que es un porcentaje. Un propósito de pruebas triviales como esta es asegurar que los errores en la lectura de la especificación sean corregidos.
[En cuanto a la edición: creo que es inevitable que una especificación incorrecta sea un punto de falla. Si no sabes lo que se supone que debe hacer la aplicación, es probable que no lo haga. Pero escribir pruebas para reflejar la especificación no aumenta este problema, simplemente no logra resolverlo. Por lo tanto, no agrega nuevos puntos de falla, solo representa las fallas existentes en el código en lugar de la documentación de waffle .]
He pensado un poco sobre una buena manera de responder a esta pregunta, y me gustaría establecer un paralelo con el método científico. OMI, podría reformular esta pregunta, "¿Cómo experimentas un experimento?"
Los experimentos verifican suposiciones empíricas (hipótesis) sobre el universo físico. Las pruebas unitarias probarán las suposiciones sobre el estado o el comportamiento del código que llaman. Podemos hablar de la validez de un experimento, pero eso se debe a que sabemos, a través de numerosos otros experimentos, que algo no encaja. No tiene validez convergente ni evidencia empírica . No diseñamos un nuevo experimento para probar o verificar la validez de un experimento , pero podemos diseñar un experimento completamente nuevo .
Por lo tanto, al igual que los experimentos , no describimos la validez de una prueba unitaria en función de si supera o no una prueba unitaria. Junto con otras pruebas unitarias, describe las suposiciones que hacemos sobre el sistema que está probando. Además, al igual que los experimentos, tratamos de eliminar tanta complejidad como podamos de lo que estamos probando. "Lo más simple posible, pero no más simple".
A diferencia de los experimentos , tenemos un truco en la manga para verificar que nuestras pruebas sean válidas además de la validez convergente. Podemos introducir inteligentemente un error que sabemos que debe ser capturado por la prueba, y ver si la prueba falla. (¡Si pudiéramos hacer eso en el mundo real, dependeríamos mucho menos de esta cuestión de validez convergente!) Una manera más eficiente de hacerlo es ver cómo falla la prueba antes de implementarla (el paso rojo en Rojo, Verde, Refactor )
Incluso si no prueba su código, seguramente será probado en producción por sus usuarios. Los usuarios son muy creativos al tratar de bloquear su soft y encontrar incluso errores no críticos.
Reparar errores en la producción es mucho más costoso que resolver problemas en la fase de desarrollo. Como efecto secundario, perderá ingresos debido a un éxodo de clientes. Puede contar con 11 clientes perdidos o no ganados por 1 cliente enojado.
La mayoría de las pruebas unitarias, suposiciones de prueba. En este caso, el precio de descuento debe ser el precio menos el descuento. Si tus suposiciones son incorrectas, apuesto a que tu código también es incorrecto. Y si comete un error tonto, la prueba fallará y la corregirá.
Si las reglas cambian, la prueba fallará y eso es algo bueno. Entonces, usted debe cambiar la prueba también en este caso.
Como regla general, si una prueba falla de inmediato (y no usa el primer diseño de la prueba), la prueba o el código es incorrecto (o ambos si tiene un mal día). Utiliza el sentido común (y posiblemente las especificaciones) para corregir el código ofensivo y volver a ejecutar la prueba.
Como dijo Jason, las pruebas son seguridad. Y sí, a veces introducen trabajo adicional debido a pruebas defectuosas. Pero la mayoría de las veces son grandes ahorradores de tiempo. (Y tienes la oportunidad perfecta para castigar al hombre que rompe la prueba (estamos hablando de pollo de goma)).
Las pruebas unitarias están ahí para que sus unidades (métodos) hagan lo que usted espera. Escribir la prueba primero te obliga a pensar en lo que esperas antes de escribir el código. Pensar antes de hacer siempre es una buena idea.
Las pruebas unitarias deben reflejar las reglas comerciales. De acuerdo, puede haber errores en el código, pero escribir la prueba primero le permite escribirlo desde la perspectiva de la regla de negocios antes de escribir cualquier código. Escribir la prueba más tarde, creo, es más probable que conduzca al error que describes porque sabes cómo el código lo implementa y te sientes tentado solo para asegurarte de que la implementación sea correcta, no porque la intención sea correcta.
Además, las pruebas unitarias son solo una forma, y la más baja, de las pruebas que debe escribir. Las pruebas de integración y las pruebas de aceptación también deben escribirse, esta última por parte del cliente, si es posible, para asegurarse de que el sistema funcione de la manera esperada. Si encuentra errores durante esta prueba, regrese y escriba las pruebas unitarias (que fallan) para probar el cambio en la funcionalidad para que funcione correctamente, luego cambie su código para que la prueba pase. Ahora tiene pruebas de regresión que capturan las correcciones de errores.
[EDITAR]
Otra cosa que he encontrado al hacer TDD. Casi obliga a un buen diseño por defecto. Esto se debe a que los diseños altamente acoplados son casi imposibles de probar en forma aislada. No toma mucho tiempo usar TDD para descubrir que usar interfaces, inversión de control e inyección de dependencia, todos patrones que mejorarán su diseño y reducirán el acoplamiento, son realmente importantes para el código comprobable.
Las pruebas unitarias son muy similares a la contabilidad de doble entrada. Usted declara lo mismo (regla comercial) de dos maneras completamente diferentes (como reglas programadas en su código de producción, y como ejemplos simples y representativos en sus pruebas). Es muy poco probable que cometa el mismo error en ambos, por lo que si ambos están de acuerdo el uno con el otro, es bastante improbable que lo hayas equivocado.
¿Cómo va a valer la pena el esfuerzo? En mi experiencia, al menos en cuatro formas, al menos cuando se realiza un desarrollo basado en pruebas:
- te ayuda a encontrar un diseño bien desacoplado. Solo puede un código de prueba unitario que está bien desacoplado;
- te ayuda a determinar cuándo terminaste. Tener que especificar el comportamiento necesario en las pruebas ayuda a no crear funcionalidades que realmente no necesita, y determinar cuándo se completó la funcionalidad;
- le brinda una red de seguridad para las refactorizaciones, lo que hace que el código sea mucho más receptivo a los cambios; y
- te ahorra mucho tiempo de depuración, que es terriblemente costoso (he escuchado estimaciones de que tradicionalmente los desarrolladores gastan hasta 80% de su tiempo de depuración).
Necesita usar el paradigma correcto al escribir pruebas.
- Comience por escribir sus pruebas primero.
- Asegúrate de que no comiencen con.
- Haz que pasen.
- Revise el código antes de registrar su código (asegúrese de que las pruebas sean revisadas).
No siempre puedes estar seguro, pero mejoran las pruebas generales.
Prueba todo lo que puedas Incluso los errores triviales, como olvidar convertir metros en pies, pueden tener efectos secundarios muy costosos. Escriba una prueba, escriba el código para verificar, haga que pase, continúe. Quién sabe en algún momento en el futuro, alguien puede cambiar el código de descuento. Una prueba puede detectar el problema.
Recuerde que el costo de corregir defectos aumenta (exponencialmente) a medida que los defectos viven durante el ciclo de desarrollo. Sí, el equipo de pruebas podría detectar el defecto, pero (normalmente) se necesitará más trabajo para aislar y corregir el defecto desde ese punto que si fallara una prueba unitaria, y será más fácil introducir otros defectos mientras se corrige si no tiene pruebas unitarias para ejecutar.
Por lo general, es más fácil de ver con algo más que un ejemplo trivial ... y con ejemplos triviales, bueno, si de alguna manera arruinas la prueba unitaria, la persona que la revise captará el error en la prueba o el error en el código, o ambos. (Están siendo revisados, ¿no?) Como señala tvanfosson , las pruebas unitarias son solo una parte de un plan SQA.
En cierto sentido, las pruebas unitarias son un seguro. No son garantía de que atraparás todos los defectos, y a veces puede parecer que gastas muchos recursos en ellos, pero cuando detectan defectos que puedes arreglar, estarás gastando mucho menos. que si no hubiera tenido ninguna prueba y tuviera que corregir todos los defectos aguas abajo.
Veo que las pruebas unitarias y el código de producción tienen una relación simbiótica. En pocas palabras: uno prueba el otro. Y ambos prueban al desarrollador.
Veo tu punto, pero es claramente exagerado.
Su argumento es básicamente: las pruebas presentan fallas. Por lo tanto, las pruebas son malas / pérdida de tiempo.
Si bien eso puede ser cierto en algunos casos, difícilmente es la mayoría.
TDD asume: Más pruebas = Menos fallas.
Las pruebas tienen más probabilidades de atrapar puntos de falla que presentarlos.