¿Vale la pena la prueba unitaria? [cerrado]

Estoy trabajando para integrar las pruebas unitarias en el proceso de desarrollo en el equipo en el que trabajo y hay algunos escépticos. ¿Cuáles son algunas buenas maneras de convencer a los escépticos desarrolladores del equipo del valor de Unit Testing? En mi caso específico, estaríamos agregando pruebas unitarias a medida que agregamos funcionalidad o errores corregidos. Lamentablemente, nuestra base de código no se presta a pruebas fáciles.

Todos los días en nuestra oficina hay un intercambio que va más o menos así:

"Hombre, me encantan las pruebas unitarias, solo pude hacer un montón de cambios en la forma en que funciona algo, y luego pude confirmar que no había roto nada al ejecutar la prueba nuevamente ..."

Los detalles cambian a diario, pero el sentimiento no. Las pruebas unitarias y el desarrollo basado en pruebas (TDD) tienen tantos beneficios ocultos y personales, así como los obvios que simplemente no puedes explicarle a alguien hasta que lo hagan ellos mismos.

Pero, ignorando eso, ¡aquí está mi intento!

1. Las pruebas unitarias le permiten realizar grandes cambios en el código rápidamente. Sabe que funciona ahora porque ha ejecutado las pruebas, cuando realiza los cambios que necesita hacer, necesita que las pruebas vuelvan a funcionar. Esto ahorra horas.

2. TDD le ayuda a darse cuenta de cuándo detener la codificación. Sus pruebas le dan la confianza de que ha hecho lo suficiente por ahora y puede dejar de ajustar y pasar a lo siguiente.

3. Las pruebas y el código trabajan juntos para lograr un mejor código. Su código podría ser malo / defectuoso. Su PRUEBA podría ser mala / con errores. En TDD, está contando con las posibilidades de que ambos sean malos / con errores bajos. A menudo es la prueba la que necesita arreglarse, pero sigue siendo un buen resultado.

4. TDD ayuda a codificar el estreñimiento. Cuando se enfrente con un trabajo grande y desalentador por delante, escribir las pruebas lo ayudará a moverse rápidamente.

5. Las pruebas unitarias lo ayudan a comprender realmente el diseño del código en el que está trabajando. En lugar de escribir código para hacer algo, está comenzando por describir todas las condiciones a las que está sometiendo el código y qué resultados esperaría de eso.

6. Las pruebas unitarias le brindan retroalimentación visual instantánea, a todos nos gusta la sensación de todas esas luces verdes cuando lo hemos hecho. Es muy satisfactorio. También es mucho más fácil retomar donde lo dejaste después de una interrupción porque puedes ver dónde llegaste: la próxima luz roja que necesita ser reparada.

7. Contrariamente a las pruebas de unidad de creencias populares, no significa escribir el doble de código o codificar más lentamente. Es más rápido y más robusto que la codificación sin pruebas una vez que lo dominas. El código de prueba en sí mismo suele ser relativamente trivial y no agrega una gran sobrecarga a lo que está haciendo. Este es uno que solo creerás cuando lo estés haciendo :)

8. Creo que fue Fowler quien dijo: "Las pruebas imperfectas, ejecutadas con frecuencia, son mucho mejores que las pruebas perfectas que nunca se escriben en absoluto". Interpreto que esto me da permiso para escribir pruebas donde creo que serán más útiles incluso si el resto de la cobertura de mi código es lamentablemente incompleta.

9. Las buenas pruebas unitarias pueden ayudar a documentar y definir qué se supone que debe hacer algo

10. Las pruebas unitarias ayudan con la reutilización del código. Migre tanto su código como sus pruebas a su nuevo proyecto. Ajusta el código hasta que las pruebas vuelvan a ejecutarse.

Una gran cantidad de trabajo en el que estoy involucrado no funciona bien en Unit Test (interacciones de usuario de aplicaciones web, etc.), pero aun así todos estamos infectados en esta tienda y somos más felices cuando tenemos nuestras pruebas atadas. No puedo recomendar el enfoque lo suficiente.

Las pruebas unitarias son muy parecidas a ir al gimnasio. Sabes que es bueno para ti, todos los argumentos tienen sentido, así que empiezas a trabajar. Hay una fiebre inicial, que es genial, pero después de unos días comienzas a preguntarte si vale la pena. Te estás tomando una hora de tu día para cambiarte de ropa y correr en una rueda de hámster y no estás seguro de que realmente estés ganando algo más que dolor en las piernas y los brazos.

Luego, después de tal vez una o dos semanas, justo cuando el dolor desaparece, comienza a acercarse un Gran Plazo. Debe pasar cada hora de vigilia tratando de hacer un trabajo "útil", de modo que elimine cosas extrañas, como ir al gimnasio. Caes del hábito y, cuando finaliza el Big Deadline, estás de vuelta al punto de partida. Si logras regresar al gimnasio, te sientes tan dolorido como la primera vez que fuiste.

Lees un poco para ver si estás haciendo algo mal. Empiezas a sentir un poco de irracional rencor hacia todas las personas felices y en forma que ensalzan las virtudes del ejercicio. Te das cuenta de que no tienes mucho en común. No tienen que conducir 15 minutos fuera del camino para ir al gimnasio; Hay uno en su edificio. No tienen que discutir con nadie sobre los beneficios del ejercicio; Es algo que todos hacen y aceptan como importante. Cuando se acerca una gran fecha límite, no se les dice que el ejercicio es innecesario más de lo que su jefe le pediría que dejara de comer.

Por lo tanto, para responder a su pregunta, las pruebas unitarias generalmente valen la pena, pero la cantidad de esfuerzo requerida no será la misma para todos. Las pruebas unitarias pueden requerir una enorme cantidad de esfuerzo si se trata de una base de código de espagueti en una empresa que en realidad no valora la calidad del código. (Muchos gerentes cantarán los elogios de Unit Testing, pero eso no significa que lo defenderán cuando sea importante).

Si estás tratando de introducir las Pruebas de Unidad en tu trabajo y no estás viendo toda la luz del sol y los arcoíris que te han esperado, no te culpes a ti mismo. Es posible que necesite encontrar un nuevo trabajo para realmente hacer que Unit Testing funcione para usted.

La mejor manera de convencer ... encuentra un error, escribe una prueba unitaria para él, corrige el error.

Es poco probable que ese error en particular vuelva a aparecer, y puede probarlo con su prueba.

Si haces esto lo suficiente, otros se darán cuenta rápidamente.

thetalkingwalnut pregunta:

¿Cuáles son algunas buenas maneras de convencer a los escépticos desarrolladores del equipo del valor de Unit Testing?

Todos aquí se van a amontonar por muchas razones de la nada por las que las pruebas unitarias son buenas. Sin embargo, creo que a menudo la mejor manera de convencer a alguien de algo es escuchar su argumento y abordarlo punto por punto. Si los escucha y los ayuda a expresar sus inquietudes, puede abordar cada uno de ellos y quizás convertirlos a su punto de vista (o al menos, dejarlos sin una pierna para pararse). ¿Quién sabe? Quizás te convencerán de por qué las pruebas unitarias no son apropiadas para tu situación. No es probable, pero posible. Quizás si publica sus argumentos en contra de las pruebas unitarias, podemos ayudar a identificar los contraargumentos.

Es importante escuchar y comprender ambos lados del argumento. Si intentas adoptar pruebas unitarias demasiado celosamente sin tener en cuenta las preocupaciones de la gente, terminarás con una guerra religiosa (y probablemente pruebas unitarias realmente inútiles). Si lo adopta lentamente y comienza aplicándolo donde verá el mayor beneficio por el menor costo, podría demostrar el valor de las pruebas unitarias y tener una mejor oportunidad de convencer a las personas. Me doy cuenta de que esto no es tan fácil como parece: por lo general, requiere algo de tiempo y métricas cuidadosas para elaborar un argumento convincente.

Las pruebas unitarias son una herramienta, como cualquier otra, y deben aplicarse de tal manera que los beneficios (capturar errores) superen los costos (el esfuerzo de escribirlos). No los use si / donde no tienen sentido y recuerde que son solo parte de su arsenal de herramientas (por ejemplo, inspecciones, afirmaciones, analizadores de código, métodos formales, etc.). Lo que les digo a mis desarrolladores es esto:

1. Pueden omitir escribir una prueba para un método si tienen un buen argumento de por qué no es necesario (por ejemplo, demasiado simple para valerlo o demasiado difícil para valerlo) y cómo se verificará el método (por ejemplo, inspección, afirmaciones , métodos formales, pruebas interactivas / de integración). Deben tener en cuenta que algunas verificaciones, como las inspecciones y las pruebas formales, se realizan en un momento dado y luego deben repetirse cada vez que cambia el código de producción, mientras que las pruebas unitarias y las afirmaciones pueden usarse como pruebas de regresión (escritas una vez y ejecutadas repetidamente después) ) A veces estoy de acuerdo con ellos, pero con mayor frecuencia debatiré si un método es realmente demasiado simple o demasiado difícil de probar por unidad.

   • Si un desarrollador argumenta que un método parece demasiado simple para fallar, ¿no vale la pena tomarse los 60 segundos necesarios para escribir una prueba unitaria simple de 5 líneas? Estas 5 líneas de código se ejecutarán todas las noches (usted hace compilaciones nocturnas, ¿verdad?) Durante el próximo año o más y valdrá la pena el esfuerzo si incluso una vez que se detecta un problema que puede haber tardado 15 minutos o más en identificarse y depurar Además, escribir las pruebas unitarias fáciles aumenta el número de pruebas unitarias, lo que hace que el desarrollador se vea bien.

   • Por otro lado, si un desarrollador argumenta que un método parece demasiado difícil de probar (no vale la pena el esfuerzo significativo requerido), tal vez eso sea una buena indicación de que el método necesita ser dividido o refactorizado para probar las partes fáciles. Por lo general, estos son métodos que se basan en recursos inusuales como singletons, la hora actual o recursos externos como un conjunto de resultados de la base de datos. Por lo general, estos métodos deben refactorizarse en un método que obtenga el recurso (por ejemplo, llamadas getTime ()) y un método que tome el recurso como argumento (por ejemplo, tome la marca de tiempo como parámetro). Les dejo pasar la prueba del método que recupera el recurso y en su lugar escriben una prueba unitaria para el método que ahora toma el recurso como argumento. Por lo general, esto hace que escribir la prueba unitaria sea mucho más simple y, por lo tanto, vale la pena escribirlo.

2. El desarrollador necesita dibujar una "línea en la arena" en cuanto a cuán exhaustivas deberían ser sus pruebas unitarias. Más adelante en el desarrollo, cada vez que encontremos un error, deberían determinar si las pruebas unitarias más completas habrían detectado el problema. Si es así y si tales errores surgen repetidamente, deben mover la "línea" para escribir pruebas unitarias más completas en el futuro (comenzando con la adición o expansión de la prueba unitaria para el error actual). Necesitan encontrar el equilibrio correcto.

Es importante darse cuenta de las pruebas de unidad no son una panacea y no es una cosa tal como demasiada pruebas unitarias. En mi lugar de trabajo, cada vez que hacemos una lección aprendida, inevitablemente escucho "necesitamos escribir más pruebas unitarias". La gerencia asiente de acuerdo porque se les ha golpeado en la cabeza que "pruebas unitarias" == "bueno".

Sin embargo, debemos comprender el impacto de "más pruebas unitarias". Un desarrollador solo puede escribir ~ N líneas de código a la semana y debe averiguar qué porcentaje de ese código debe ser un código de prueba unitario versus un código de producción. Un lugar de trabajo laxo podría tener el 10% del código como pruebas unitarias y el 90% del código como código de producción, lo que da como resultado un producto con muchas características (aunque muy defectuosas) (piense en MS Word). Por otro lado, una tienda estricta con 90% de pruebas unitarias y 10% de código de producción tendrá un producto sólido como una roca con muy pocas características (piense en "vi"). Es posible que nunca escuche informes sobre la caída del último producto, pero es probable que tenga tanto que ver con que el producto no se venda tan bien como con la calidad del código.

Peor aún, quizás la única certeza en el desarrollo de software es que "el cambio es inevitable". Suponga que la tienda estricta (90% de pruebas unitarias / 10% de código de producción) crea un producto que tiene exactamente 2 características (suponiendo que el 5% del código de producción == 1 característica). Si el cliente aparece y cambia 1 de las características, entonces ese cambio desecha el 50% del código (45% de las pruebas unitarias y el 5% del código de producción). La tienda laxa (10% de pruebas unitarias / 90% de código de producción) tiene un producto con 18 características, ninguna de las cuales funciona muy bien. Su cliente renueva por completo los requisitos para 4 de sus características. Aunque el cambio es 4 veces mayor, solo la mitad de la base del código se destruye (~ 25% = ~ 4.4% pruebas unitarias + 20% del código de producción).

Mi punto es que tiene que comunicar que comprende el equilibrio entre muy poca y demasiada prueba de unidad, esencialmente que ha pensado en ambos lados del problema. Si puede convencer a sus pares y / o su gerencia de eso, gana credibilidad y quizás tenga una mejor oportunidad de ganárselos.

He jugado con las pruebas unitarias varias veces, y todavía estoy convencido de que vale la pena el esfuerzo dada mi situación.

Desarrollo sitios web, donde gran parte de la lógica implica crear, recuperar o actualizar datos en la base de datos. Cuando traté de "burlarme" de la base de datos para propósitos de pruebas unitarias, se puso muy desordenada y parecía un poco inútil.

Cuando he escrito pruebas unitarias en torno a la lógica de negocios, nunca me ha ayudado a largo plazo. Debido a que trabajo principalmente en proyectos solos, tiendo a saber intuitivamente qué áreas del código pueden verse afectadas por algo en lo que estoy trabajando, y pruebo estas áreas manualmente. Quiero ofrecer una solución a mi cliente lo más rápido posible, y las pruebas unitarias a menudo parecen una pérdida de tiempo. Enumero las pruebas manuales y las reviso yo mismo, marcándolas a medida que avanzo.

Puedo ver que puede ser beneficioso cuando un equipo de desarrolladores está trabajando en un proyecto y actualizando el código del otro, pero incluso entonces creo que si los desarrolladores son de alta calidad, una buena comunicación y un código bien escrito a menudo deberían ser suficientes. .

Una gran cosa acerca de las pruebas unitarias es que sirven como documentación de cómo debe comportarse su código. Las buenas pruebas son como una implementación de referencia, y los compañeros de equipo pueden mirarlas para ver cómo integrar su código con el suyo.

Las pruebas unitarias bien valen la inversión inicial. Desde que comencé a usar las pruebas unitarias hace un par de años, he encontrado algunos beneficios reales:

• Las pruebas de regresión eliminan el miedo a realizar cambios en el código (no hay nada como el cálido resplandor de ver el código funcionar o explotar cada vez que se realiza un cambio)
• ejemplos de código ejecutable para otros miembros del equipo (y usted mismo dentro de seis meses ...)
• refactorización despiadada : esto es increíblemente gratificante, ¡pruébalo!

Los fragmentos de código pueden ser de gran ayuda para reducir la sobrecarga de crear pruebas. No es difícil crear fragmentos que permitan la creación de un esquema de clase y un accesorio de prueba de unidad asociado en segundos.

¡Debes probar lo menos posible!

es decir, deberías escribir suficientes pruebas unitarias para revelar la intención. Esto a menudo se pasa por alto. Las pruebas unitarias le cuestan. Si realiza cambios y tiene que cambiar las pruebas, será menos ágil. Mantenga las pruebas unitarias cortas y dulces. Entonces tienen mucho valor.

Con demasiada frecuencia veo muchas pruebas que nunca se romperán, son grandes y torpes y no ofrecen mucho valor, simplemente terminan desacelerándote.

No vi esto en ninguna de las otras respuestas, pero una cosa que noté es que podía depurar mucho más rápido . No necesita profundizar a través de su aplicación con la secuencia correcta de pasos para llegar al código que está arreglando, solo para descubrir que ha cometido un error booleano y necesita hacerlo todo de nuevo. Con una prueba unitaria, puede pasar directamente al código que está depurando.

[Tengo un punto para hacer que no puedo ver arriba]

"Todas las pruebas unitarias, no necesariamente se dan cuenta - HECHO"

Piénselo, escribe una función para analizar una cadena y eliminar nuevos caracteres de línea. Como desarrollador novato, puede ejecutar algunos casos desde la línea de comandos al implementarlo en Main () o unir una interfaz visual con un botón, vincular su función a un par de cuadros de texto y un botón y ver lo que pasa.

Es una prueba unitaria: básica y mal organizada, pero se prueba el código por algunos casos.

Escribes algo más complejo. Sin embargo, arroja errores cuando arroja algunos casos (pruebas unitarias) y depura en el código y rastrea. Observa los valores a medida que avanza y decide si son correctos o incorrectos. Esta es la prueba unitaria hasta cierto punto.

Las pruebas unitarias aquí realmente están tomando ese comportamiento, formalizándolo en un patrón estructurado y guardándolo para que pueda volver a ejecutar fácilmente esas pruebas. Si escribe un caso de prueba de unidad "adecuado" en lugar de probarlo manualmente, lleva la misma cantidad de tiempo, o tal vez menos que lo que tenga experiencia, y lo tiene disponible para repetir una y otra vez

Durante años, he tratado de convencer a la gente de que necesitaban escribir pruebas unitarias para su código. Si escribieron las pruebas primero (como en TDD) o después de codificar la funcionalidad, siempre traté de explicarles todos los beneficios de tener pruebas unitarias para el código. Casi nadie estuvo en desacuerdo conmigo. No puede estar en desacuerdo con algo que es obvio, y cualquier persona inteligente verá los beneficios de la prueba de unidad y TDD.

El problema con las pruebas unitarias es que requiere un cambio de comportamiento, y es muy difícil cambiar el comportamiento de las personas. Con palabras, muchas personas estarán de acuerdo contigo, pero no verás muchos cambios en la forma en que hacen las cosas.

Tienes que convencer a la gente haciendo. Su éxito personal atraerá a más personas que todos los argumentos que pueda tener. Si ven que no solo estás hablando de la prueba de unidad o TDD, sino que estás haciendo lo que predicas y tienes éxito, la gente tratará de imitarte.

También debe asumir un papel principal porque nadie escribe la prueba de unidad correctamente la primera vez, por lo que es posible que deba capacitarlos sobre cómo hacerlo, mostrarles el camino y las herramientas disponibles para ellos. Ayúdelos mientras escriben sus primeras pruebas, repase las pruebas que escriben por su cuenta y muéstreles los trucos, modismos y patrones que ha aprendido a través de sus propias experiencias. Después de un tiempo, comenzarán a ver los beneficios por sí mismos y cambiarán su comportamiento para incorporar pruebas unitarias o TDD en su caja de herramientas.

Los cambios no sucederán durante la noche, pero con un poco de paciencia, puede lograr su objetivo.

Una parte importante del desarrollo basado en pruebas que a menudo se pasa por alto es la escritura de código comprobable. Al principio parece una especie de compromiso, pero descubrirá que el código comprobable también es en última instancia modular, mantenible y legible. Si aún necesita ayuda para convencer a la gente, esta es una presentación simple y agradable sobre las ventajas de las pruebas unitarias.

Si su base de código existente no se presta para pruebas unitarias, y ya está en producción, puede crear más problemas de los que resuelve al tratar de refactorizar todo su código para que sea comprobable por unidades.

Puede que sea mejor poner esfuerzos para mejorar las pruebas de integración. Hay un montón de código por ahí que es más simple de escribir sin una prueba unitaria, y si un control de calidad puede validar la funcionalidad contra un documento de requisitos, entonces ya está. Envíalo.

El ejemplo clásico de esto en mi mente es un SqlDataReader incrustado en una página ASPX vinculada a un GridView. El código está todo en el archivo ASPX. El SQL está en un procedimiento almacenado. ¿Qué pruebas de unidad? Si la página hace lo que se supone que debe hacer, ¿realmente debería rediseñarla en varias capas para que tenga algo que automatizar?

Una de las mejores cosas de las pruebas unitarias es que su código será más fácil de probar a medida que lo haga. El código preexistente creado sin pruebas siempre es un desafío porque, dado que no estaban destinadas a ser probadas por unidades, no es raro tener un alto nivel de acoplamiento entre clases, objetos difíciles de configurar dentro de su clase, como un correo electrónico enviando referencia de servicio, y así sucesivamente. ¡Pero no dejes que esto te deprima! Verá que su diseño de código general mejorará a medida que comience a escribir pruebas unitarias, y cuanto más pruebe, más confianza tendrá en realizar aún más cambios sin temor a romper su aplicación o introducir errores .

Hay varias razones para probar su código de forma unitaria, pero a medida que pasa el tiempo, descubrirá que el tiempo que ahorra en las pruebas es una de las mejores razones para hacerlo. En un sistema que acabo de entregar, insistí en hacer pruebas unitarias automáticas a pesar de las afirmaciones de que pasaría mucho más tiempo haciendo las pruebas que probando el sistema manualmente. Con todas mis pruebas unitarias realizadas, ejecuto más de 400 casos de prueba en menos de 10 minutos, y cada vez que tenía que hacer un pequeño cambio en el código, todo lo que me tomaba para asegurarme de que el código todavía funcionaba sin errores era diez minutos. ¿Te imaginas el tiempo que pasarías para ejecutar esos más de 400 casos de prueba a mano?

Cuando se trata de pruebas automatizadas, ya sea pruebas unitarias o pruebas de aceptación, todos piensan que es un esfuerzo desperdiciado codificar lo que puede hacer manualmente, y a veces es cierto, si planea ejecutar sus pruebas solo una vez. La mejor parte de las pruebas automatizadas es que puede ejecutarlas varias veces sin esfuerzo, y después de la segunda o tercera ejecución, el tiempo y el esfuerzo que ha desperdiciado ya están pagados.

Un último consejo sería no solo probar el código de la unidad, sino comenzar a hacer la prueba primero (vea TDD y BDD para más información)

Las pruebas unitarias también son especialmente útiles cuando se trata de refactorizar o reescribir un código de una pieza. Si tiene una buena cobertura de pruebas unitarias, puede refactorizar con confianza. Sin pruebas unitarias, a menudo es difícil asegurarse de que no haya roto nada.

En resumen, sí. Vale la pena cada onza de esfuerzo ... hasta cierto punto. Al final del día, las pruebas siguen siendo código, y al igual que el típico crecimiento del código, sus pruebas eventualmente deberán ser refactorizadas para que sean sostenibles y sostenibles. ¡Hay una tonelada de GOTCHAS! cuando se trata de pruebas unitarias, pero man oh man oh man, nada, y quiero decir NADA permite que un desarrollador realice cambios con mayor confianza que un rico conjunto de pruebas unitarias.

Estoy trabajando en un proyecto en este momento ... es algo TDD, y tenemos la mayoría de nuestras reglas de negocios encapsuladas como pruebas ... tenemos alrededor de 500 pruebas unitarias en este momento. En esta iteración anterior, tuve que renovar nuestra fuente de datos y cómo nuestra aplicación de escritorio interactúa con esa fuente de datos. Me tomó un par de días, todo el tiempo seguí ejecutando pruebas unitarias para ver qué rompí y lo arreglé. Hacer un cambio; Construye y ejecuta tus pruebas; arregla lo que rompiste. Lavar, enjuagar, repetir según sea necesario. Lo que tradicionalmente habría llevado días de control de calidad y mucho estrés en el barco fue, en cambio, una experiencia corta y agradable.

Prepárese por adelantado, un poco de esfuerzo adicional, y paga 10 veces más adelante cuando tiene que comenzar a jugar con las características / funcionalidades principales.

Compré este libro, es una Biblia de conocimiento de xUnit Testing, es probablemente uno de los libros más referenciados en mi estante, y lo consulto a diario: texto del enlace

Ocasionalmente, yo o uno de mis compañeros de trabajo pasará un par de horas llegando al fondo de un error levemente oscuro y una vez que se encuentre la causa del error, el 90% del tiempo ese código no se prueba en la unidad. La prueba de la unidad no existe porque el desarrollador está cortando esquinas para ahorrar tiempo, pero luego pierde esto y más depuración.

Tomar el poco tiempo para escribir una prueba unitaria puede ahorrarle horas de depuración futura.

Estoy trabajando como ingeniero de mantenimiento de una base de código mal documentada, horrible y grande. Desearía que las personas que escribieron el código hayan escrito las pruebas unitarias para ello.
Cada vez que hago un cambio y actualizo el código de producción, tengo miedo de poder introducir un error por no haber considerado alguna condición.
Si escribieran la prueba, hacer cambios en la base del código sería más fácil y rápido (al mismo tiempo, la base del código estaría en un mejor estado).

Creo que las pruebas unitarias resultan muy útiles al escribir api o frameworks que tienen que durar muchos años y ser utilizados / modificados / evolucionados por personas que no sean los codificadores originales.

Las pruebas unitarias definitivamente valen la pena. Lamentablemente, ha elegido un escenario difícil (pero desafortunadamente común) en el que implementarlo.

El mejor beneficio de las pruebas unitarias que obtendrá es al usarlas desde cero: en algunos proyectos pequeños y selectos, tuve la suerte de escribir mis pruebas unitarias antes de implementar mis clases (la interfaz ya estaba completa en este momento punto). Con las pruebas unitarias adecuadas, encontrará y corregirá errores en sus clases mientras todavía están en su infancia y no cerca del complejo sistema en el que sin duda se integrarán en el futuro.

Si su software está sólidamente orientado a objetos, debería poder agregar pruebas unitarias a nivel de clase sin demasiado esfuerzo. Si no eres tan afortunado, aún debes intentar incorporar pruebas unitarias siempre que puedas. Cuando agregue nuevas funcionalidades, asegúrese de que las nuevas piezas estén bien definidas con interfaces claras y encontrará que las pruebas unitarias le hacen la vida mucho más fácil.

Cuando dijo: "nuestra base de código no se presta para pruebas fáciles" es el primer signo de un olor a código. Escribir pruebas unitarias significa que normalmente escribe el código de manera diferente para que el código sea más verificable. En mi opinión, esto es algo bueno, ya que lo que he visto a lo largo de los años escribiendo código para el que tuve que escribir pruebas, me obligó a presentar un mejor diseño.

Yo no sé. Muchos lugares no hacen pruebas unitarias, pero la calidad del código es buena. Microsoft hace pruebas unitarias, pero Bill Gates dio una pantalla azul en su presentación.

Escribí una publicación de blog muy grande sobre el tema. Descubrí que las pruebas unitarias por sí solas no valen la pena y generalmente se reducen cuando se acercan los plazos.

En lugar de hablar acerca de las pruebas unitarias desde el punto de vista de verificación "prueba después", debemos mirar el valor verdadero que se encuentra cuando se propone escribir una especificación / prueba / idea antes de la implementación.

Esta idea simple ha cambiado la forma en que escribo el software y no volvería a la forma "antigua".

Cómo el primer desarrollo de prueba cambió mi vida

Sí, las pruebas unitarias definitivamente valen la pena, pero debes saber que no es una bala de plata. Unit Testing es un trabajo y tendrá que trabajar para mantener la prueba actualizada y relevante a medida que el código cambia, pero el valor ofrecido vale la pena el esfuerzo que debe realizar. La capacidad de refactorizar impunemente es un gran beneficio ya que siempre puede validar la funcionalidad ejecutando sus pruebas después de cualquier código de cambio. El truco consiste en no obsesionarse demasiado con la unidad de trabajo que está probando o con los requisitos de la prueba de andamiaje y cuando una prueba de unidad es realmente una prueba funcional, etc. La gente discutirá sobre esto durante horas. y la realidad es que cualquier prueba que realice como código de escritura es mejor que no hacerlo. El otro axioma es sobre calidad y no cantidad: he visto bases de código con 1000 ' s de prueba que esencialmente no tienen sentido ya que el resto no prueba realmente nada útil o algo específico del dominio como las reglas de negocios, etc. del dominio particular. También he visto bases de código con una cobertura de código del 30%, pero las pruebas fueron relevantes, significativas y realmente asombrosas, ya que probaron la funcionalidad central del código para el que fue escrito y expresaron cómo se debe usar el código.

Uno de mis trucos favoritos al explorar nuevos frameworks o bases de código es escribir pruebas unitarias para 'ello' para descubrir cómo funcionan las cosas. Es una excelente manera de aprender más sobre algo nuevo en lugar de leer un documento seco :)

Recientemente pasé por la misma experiencia en mi lugar de trabajo y descubrí que la mayoría de ellos conocía los beneficios teóricos, pero tenía que venderlos específicamente para ellos, así que aquí están los puntos que utilicé (con éxito):

• Ahorran tiempo al realizar pruebas negativas, donde maneja entradas inesperadas (punteros nulos, valores fuera de límites, etc.), ya que puede hacer todo esto en un solo proceso.
• Proporcionan retroalimentación inmediata en tiempo de compilación con respecto al estándar de los cambios.
• Son útiles para probar representaciones de datos internos que pueden no estar expuestos durante el tiempo de ejecución normal.

y el grande ...

• Es posible que no necesite pruebas unitarias, pero cuando alguien más entra y modifica el código sin una comprensión completa, puede detectar muchos de los errores tontos que podrían cometer.

Descubrí TDD hace un par de años, y desde entonces he escrito todos mis proyectos favoritos usándolo. Calculé que se necesita aproximadamente el mismo tiempo para TDD un proyecto que para juntarlo, pero tengo tanta confianza en el producto final que no puedo evitar una sensación de logro.

También siento que mejora mi estilo de diseño (mucho más orientado a la interfaz en caso de que necesite burlarme de las cosas) y, como escribe la publicación verde en la parte superior, ayuda a "codificar el estreñimiento": cuando no sabes qué para escribir a continuación, o si tienes una tarea desalentadora frente a ti, puedes escribir en pequeño.

Finalmente, encuentro que, con mucho, la aplicación más útil de TDD está en la depuración, aunque solo sea porque ya has desarrollado un marco interrogatorio con el que puedes impulsar el proyecto para que produzca el error de manera repetible.

Una cosa que nadie ha mencionado aún es obtener el compromiso de todos los desarrolladores para ejecutar y actualizar cualquier prueba automatizada existente. Las pruebas automatizadas a las que regresa y encuentra que no funcionan debido al nuevo desarrollo pierden mucho valor y hacen que las pruebas automatizadas sean realmente dolorosas. La mayoría de esas pruebas no indicarán errores ya que el desarrollador ha probado el código manualmente, por lo que el tiempo dedicado a actualizarlos es un desperdicio.

Convencer a los escépticos de que no destruyan el trabajo que los demás están haciendo en las pruebas unitarias es mucho más importante para obtener valor de las pruebas y podría ser más fácil.

Pasar horas actualizando las pruebas que se han roto debido a las nuevas características cada vez que actualiza desde el repositorio no es productivo ni divertido.

Si está utilizando NUnit, una demostración simple pero efectiva es ejecutar el (los) propio (s) conjunto (s) de prueba de NUnit frente a ellos. Ver un conjunto de pruebas real que le da un entrenamiento a una base de código vale más que mil palabras ...

Las pruebas unitarias ayudan mucho en proyectos que son más grandes de lo que cualquier desarrollador puede tener en su cabeza. Le permiten ejecutar el conjunto de pruebas unitarias antes de registrarse y descubrir si rompió algo. Esto reduce mucho las instancias de tener que sentarse y girar los pulgares mientras espera que alguien más corrija un error que revisaron, o se toma la molestia de revertir su cambio para que pueda hacer un poco de trabajo. También es inmensamente valioso en la refactorización, por lo que puede estar seguro de que el código refactorizado pasa todas las pruebas que hizo el código original.

Con el conjunto de pruebas unitarias, uno puede hacer cambios en el código mientras deja el resto de las características intactas. Es una gran ventaja. ¿Utiliza la unidad de prueba de sutie y el conjunto de pruebas de regresión cuando termina de codificar una nueva función?

Estoy de acuerdo con el punto de vista opuesto a la mayoría aquí: está bien no escribir pruebas unitarias Especialmente, la programación pesada de prototipos (IA, por ejemplo) es difícil de combinar con las pruebas unitarias.