Diferencia horaria entre el desarrollo con pruebas unitarias y sin pruebas

132

Soy un desarrollador en solitario con un entorno de trabajo bastante limitado en el tiempo, donde el tiempo de desarrollo generalmente varía de 1 a 4 semanas por proyecto, dependiendo de los requisitos, la urgencia o ambos. En cualquier momento manejo alrededor de 3-4 proyectos, algunos con líneas de tiempo que se superponen entre sí.

Como era de esperar, la calidad del código sufre. Tampoco tengo pruebas formales; Por lo general, pasa a caminar por el sistema hasta que se rompe un poco. Como resultado, una cantidad considerable de errores escapan a la producción, que tengo que arreglar y, a su vez, retrasa mis otros proyectos.

Aquí es donde intervienen las pruebas unitarias. Cuando se hace correctamente, debe mantener los errores, y mucho menos los que escapan a la producción, al mínimo. Por otro lado, escribir pruebas puede llevar una cantidad considerable de tiempo, lo que no suena bien con proyectos con limitaciones de tiempo como el mío.

La pregunta es, ¿qué diferencia de tiempo escribiría el código probado en la unidad sobre el código no probado, y cómo se escala esa diferencia de tiempo a medida que se amplía el alcance del proyecto?

Revenant
fuente
Los comentarios no son para discusión extendida; Esta conversación se ha movido al chat .
maple_shaft
8
Estás resolviendo el problema equivocado. Está demasiado ocupado y parece no tener soporte de gestión de proyectos. ¿Estás estimando el esfuerzo del proyecto? ¿Está reservando el 20% de su tiempo para la corrección de errores, reuniones y otras tareas sin codificación? ¿Cuánto tiempo extra estás trabajando?
Tony Ennis
20
¿Te das cuenta de que esencialmente estás diciendo "Tengo tiempo para hacerlo dos veces, pero no tiempo para hacerlo una vez de la manera correcta"?
RubberDuck
55
@RubberDuck en realidad hay un punto en la curva de la complejidad del proyecto medido como Tiempo de escritura vs Tiempo de prueba, donde "Exprimirlo dos veces", lleva menos tiempo que "Escríbelo y son pruebas". Creo que puede estar en algún lugar de la región de un bash oneliner.
Lyndon White
Una vez los desarrolladores recibieron regalos y gracias cuando se canceló un proyecto. Señalé que podríamos haber sido aún más productivos si hubiéramos sabido que el producto no se enviaría. Entonces, este es un caso en el que desarrollar sin probar sería ventajoso.
JDługosz

Respuestas:

148

Cuanto más tarde realice la prueba, más le costará escribir pruebas.

Cuanto más dura un error, más costoso es arreglarlo.

La ley de rendimientos decrecientes asegura que pueda probarse a sí mismo en el olvido tratando de asegurarse de que no haya errores.

Buda enseñó la sabiduría del camino del medio. Las pruebas son buenas. Existe algo demasiado bueno. La clave es saber cuándo estás fuera de balance.

Cada línea de código que escriba sin pruebas tendrá costos significativamente mayores para agregar pruebas más tarde que si hubiera escrito las pruebas antes de escribir el código.

Cada línea de código sin pruebas será significativamente más difícil de depurar o reescribir.

Cada examen que escriba llevará tiempo.

Cada error llevará tiempo para solucionarlo.

Los fieles le dirán que no escriba una sola línea de código sin primero escribir una prueba fallida. La prueba asegura que está obteniendo el comportamiento que espera. Le permite cambiar el código rápidamente sin preocuparse de afectar al resto del sistema, ya que la prueba demuestra que el comportamiento es el mismo.

Debe comparar todo eso con el hecho de que las pruebas no agregan características. El código de producción agrega características. Y las características son las que pagan las facturas.

Hablando pragmáticamente, agrego todas las pruebas que puedo hacer. Ignoro los comentarios a favor de ver las pruebas. Ni siquiera confío en el código para hacer lo que creo que hace. Confío en las pruebas. Pero se me conoce por lanzar ocasionalmente el granizo de María y tener suerte.

Sin embargo, muchos codificadores exitosos no hacen TDD. Eso no significa que no prueben. Simplemente no insisten obsesivamente en que cada línea de código tenga una prueba automatizada en su contra. Incluso el tío Bob admite que no prueba su interfaz de usuario. También insiste en que elimines toda la lógica de la interfaz de usuario.

Como metáfora del fútbol (eso es fútbol americano), TDD es un buen juego de tierra. Las pruebas manuales solo donde escribes un montón de código y esperas que funcionen son un juego de pasar. Puedes ser bueno en cualquiera de los dos. Tu carrera no va a llegar a los playoffs a menos que puedas hacer ambas cosas. No formará el superbowl hasta que aprenda cuándo elegir cada uno. Pero si necesita un empujón en una dirección particular: las llamadas de los funcionarios van en mi contra más a menudo cuando paso.

Si desea probar TDD, le recomiendo que practique antes de intentar hacerlo en el trabajo. TDD hecho a la mitad, a medias y a medias es una gran razón por la que algunos no lo respetan. Es como verter un vaso de agua en otro. Si no te comprometes y lo haces rápida y completamente, terminas goteando agua por toda la mesa.

naranja confitada
fuente
68
Hay demasiadas cosas buenas. Ni usted ni Buda han probado las galletas de mi abuela :-)
Pierre Arlaud
3
@NickAlexeev Me encanta ese gráfico allí. Una cosa que no señala es que las pruebas unitarias (que generalmente son automáticas) son realmente buenas para encontrar errores cuando se modifica el código. Me encantaría ver eso dividido en "errores encontrados antes del lanzamiento" y "errores encontrados después del lanzamiento". Las pruebas unitarias son la mejor línea de defensa contra la regresión.
corsiKa
3
Creo que esta es una respuesta muy equilibrada: probar todo, incluso cosas triviales, puede ser una pérdida de tiempo. Tener buenas pruebas para las partes complejas que pueden romperse fácilmente realmente puede ayudar. Acabo de terminar de portar un proyecto pequeño pero no trivial de Java a C ++. Primero porté las pruebas y esto me guió a configurar toda la implementación de C ++. Una vez que todas las pruebas fueron verdes, solo se necesitaron algunas clases más fáciles de portar y todo salió sin problemas. Por otro lado, no tengo pruebas para todo el código: esto habría prolongado la implementación en al menos 3, 4 días con poca ganancia.
Giorgio
55
Un ligero desacuerdo con esto: 'Debe sopesar todo eso contra el hecho de que las pruebas no agregan características. El código agrega características. Y las características son las que pagan las cuentas. Sugeriría encarecidamente que no son las características las que pagan las facturas, sino las funciones de trabajo. (¿O se les paga a las personas por entregas que no funcionan?). El resto de la respuesta estoy completamente de acuerdo.
Tony Suffolk 66
66
@ TonySuffolk66 tienes razón, son las funciones de trabajo las que pagan las facturas (salvo la venta de flimflam) Sin embargo, la gente estaba creando funciones de trabajo mucho antes de que TDD fuera una cosa. Lo harán mucho después de que se haya ido. Recuerde, TDD es una forma disciplinada de prueba. No es la única forma disciplinada de prueba.
candied_orange
112

Estoy de acuerdo con el resto de las respuestas, pero para responder directamente a la pregunta cuál es la diferencia horaria .

Roy Osherove, en su libro The Art of Unit Testing, Segunda edición, página 200, hizo un estudio de caso sobre la implementación de proyectos de tamaño similar con equipos similares (en cuanto a habilidades) para dos clientes diferentes donde un equipo hizo pruebas mientras que el otro no.

Sus resultados fueron así:

Progreso y rendimiento del equipo medidos con y sin pruebas

Entonces, al final de un proyecto obtienes menos tiempo y menos errores. Esto, por supuesto, depende de qué tan grande es un proyecto.

Aki K
fuente
32
El tamaño de la muestra es demasiado pequeño para considerar que esto es científico, pero creo que es representativo de lo que experimenta mucha gente. Encuentro que cuando hago TDD, la mayor parte del tiempo extra se dedica a corregir los errores que hacen que mis pruebas unitarias fallen, no a escribir las pruebas por sí mismas. Eso no es realmente agregar tiempo extra, solo cambiar cuando encuentras y solucionas esos problemas. Cualquier tiempo extra real es para solucionar problemas que no habría encontrado, al menos no en la primera ronda.
JimmyJames
77
@JimmyJames Es un estudio de caso, que se usa ampliamente en los negocios y mucho en ciencia cuando (todavía) no es posible realizar un experimento reproducible a gran escala. Hay revistas de psicología llenas de ellas. "No científico" no es la palabra correcta.
djechlin
25
¿Por qué creo que si el resultado de ese estudio de caso hubiera mostrado lo contrario, no habría aparecido en el libro ;-)?
Doc Brown
11
@DocBrown Me pregunto cuántos estudios de caso se hicieron y descartaron antes de encontrar uno con las respuestas correctas :-)
gbjbaanb
66
@JimmyJames que casi ciertamente califica como ciencia. Además, otro científico puede leer este estudio de caso "n = 1", decidir si vale la pena estudiar más, luego realizar un estudio estadístico a gran escala, o incluso un experimento controlado longitudinalmente, y confirmarlo o negarlo. Así es exactamente como funciona la ciencia. Así es como se supone que debe funcionar. puede leer más sobre cómo funciona la ciencia aquí en.wikipedia.org/wiki/Scientific_method
djechlin
30

Solo conozco un estudio que estudió esto en un "entorno del mundo real": lograr una mejora de la calidad a través del desarrollo basado en pruebas: resultados y experiencias de cuatro equipos industriales . Es costoso hacer esto de una manera sensata, ya que básicamente significa que necesita desarrollar el mismo software dos veces (o idealmente incluso más a menudo) con equipos similares, y luego tirar todos menos uno.

Los resultados del estudio fueron un aumento en el tiempo de desarrollo entre el 15% y el 35% (que no se acerca a la cifra 2x que suelen citar los críticos de TDD) y una disminución en la densidad de defectos previos a la liberación del 40% al 90% (! ) Tenga en cuenta que todos los equipos no tenían experiencia previa con TDD, por lo que se podría suponer que el aumento en el tiempo puede atribuirse al menos parcialmente al aprendizaje y, por lo tanto, se reduciría aún más con el tiempo, pero el estudio no lo evaluó.

Tenga en cuenta que este estudio trata sobre TDD, y su pregunta es sobre pruebas unitarias, que son cosas muy diferentes, pero es lo más cercano que pude encontrar.

Jörg W Mittag
fuente
1
Sería más interesante imponer restricciones adicionales: sin estado mutable, después de SÓLIDO, tipeo estático, sin depender null, funcional sobre imperativo, contratos de código, análisis estático, refactorización automatizada, sin contenedores IoC (pero DI), etc. Apuesto ese valor de pruebas unitarias disminuiría (pero no desaparecería).
Den
24

Bien hecho, el desarrollo con pruebas unitarias puede ser más rápido incluso sin tener en cuenta los beneficios de los errores adicionales que se detectan.

El hecho es que no soy un codificador lo suficientemente bueno como para que mi código funcione tan pronto como se compila. Cuando escribo / modifico código, tengo que ejecutar el código para asegurarme de que haga lo que pensé que hace. En un proyecto, esto tendía a terminar pareciendo:

  1. Modificar código
  2. Compilar la aplicación
  3. Ejecutar aplicación
  4. Inicie sesión en la aplicación
  5. Abre una ventana
  6. Seleccione un elemento de esa ventana para abrir otra ventana
  7. Establezca algunos controles en esa ventana y haga clic en un botón

Y, por supuesto, después de todo eso, usualmente tomaba algunos viajes de ida y vuelta para hacerlo bien.

Ahora, ¿qué pasa si estoy usando pruebas unitarias? Entonces el proceso se parece más a:

  1. Escribir una prueba
  2. Ejecute pruebas, asegúrese de que falla de la manera esperada
  3. Escribir código
  4. Ejecute las pruebas nuevamente, vea que pasa

Esto es más fácil y rápido que probar manualmente la aplicación. Todavía tengo que ejecutar manualmente la aplicación (por lo que no me veo tonto cuando entrego un trabajo que en realidad no funciona en absoluto), pero en su mayor parte ya he resuelto los problemas, y solo estoy verificando en ese punto. En realidad, normalmente hago este ciclo aún más estricto mediante el uso de un programa que vuelve a ejecutar automáticamente mis pruebas cuando guardo.

Sin embargo, esto depende de trabajar en una base de código amigable para las pruebas. Muchos proyectos, incluso aquellos con muchas pruebas, dificultan las pruebas de escritura. Pero si trabaja en ello, puede tener una base de código que sea más fácil de probar mediante pruebas automatizadas que con pruebas manuales. Como beneficio adicional, puede mantener las pruebas automatizadas y seguir ejecutándolas para evitar regresiones.

Winston Ewert
fuente
1
Y usar algo como nCrunch puede reducir los pasos 2 y 4, haciendo que el ciclo de retroalimentación sea aún más estricto.
Eufórico
"Todavía tengo que ejecutar manualmente la aplicación" es una observación importante, en mi humilde opinión. No hay balas de plata.
Den
20

A pesar de que ya hay muchas respuestas, son algo repetitivas y me gustaría tomar un rumbo diferente. Las pruebas unitarias son valiosas, si y solo si , aumentan el valor comercial . Las pruebas por el bien de las pruebas (pruebas triviales o tautológicas), o para alcanzar alguna métrica arbitraria (como la cobertura del código), es una programación de culto a la carga.

Las pruebas son costosas, no solo en el tiempo que lleva escribirlas, sino también en el mantenimiento. Deben mantenerse sincronizados con el código que prueban o no valen nada. Sin mencionar el costo de tiempo de ejecutarlos en cada cambio. Eso no es un factor decisivo (o una excusa para no hacer los realmente necesarios), pero debe tenerse en cuenta para el análisis de costo-beneficio.

Entonces, la pregunta que debe hacerse al decidir si (o de qué tipo) probar o no una función / método, pregúntese "¿qué valor de usuario final estoy creando / salvaguardando con esta prueba?". Si no puede responder a esta pregunta, la parte superior de la cabeza , entonces es probable que no vale la pena el costo de la escritura / el mantenimiento de esa prueba. (o no comprende el dominio del problema, que es un problema mucho más grande que la falta de pruebas).

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

Jared Smith
fuente
1
No estoy muy familiarizado con BDD, pero supongo que funciona con una granularidad ligeramente más gruesa que el nivel de método / función y probablemente tiene una conexión menos tenue al valor del usuario.
Jared Smith
1
Relacionado
Robbie Dee
99
"Las pruebas por el bien de las pruebas (pruebas triviales o tautológicas), o para alcanzar alguna métrica arbitraria (como la cobertura del código), es una programación de culto a la carga". Tan cierto y tan bien dicho. Haga la prueba de tal manera que se sienta como un tipo genial: piense en usted como un ... espía, atleta de élite ... NO haga la prueba como un "departamento gubernamental". ¿Ya sabes?
Fattie
2
@SteveJessop no está de acuerdo, la cobertura del código (en el sentido de ser una métrica) es inherentemente arbitraria: el número de rutas a través de un programa no trivial en el nivel de instrucción de la máquina (es decir, el que cuenta) será mayor que el número de átomos en Tierra o posiblemente incluso el universo visible. Esto no es comprobable. Por lo tanto, cualquier reclamo de 'cobertura de código' se hará a un umbral arbitrario elegido heurísticamente . Los programadores son buenos para jugar tales métricas a expensas de las cosas que realmente importan.
Jared Smith
2
También diría que las pruebas proporcionan un valor comercial aproximadamente (aunque no con precisión) cada vez que fallan, y la resolución es mejorar el código bajo prueba. Entonces, si está utilizando TDD, eso ocurre casi automáticamente al menos uno por prueba. Las pruebas tautológicas por definición no pueden fallar y, por lo tanto, son inútiles. Para las pruebas "triviales": después de haber trabajado con Java TCK al principio de mi carrera, ya no me sorprende cuán trivial de una prueba es posible que falle al volver a implementar una API desde cero ;-) Pero el valor comercial es casi siempre se predice heurísticamente, por lo que también es "arbitrario".
Steve Jessop
9

Depende de la persona, así como de la complejidad y la forma del código con el que está trabajando.

Para mí, en la mayoría de los proyectos, escribir pruebas unitarias significa que hago el trabajo un 25% más rápido. Sí, incluso incluyendo el tiempo para escribir las pruebas.

Porque el hecho es que el software no se hace cuando se escribe el código. Se realiza cuando se lo envía al cliente y están contentos con él. Las pruebas unitarias son, con mucho, la forma más eficiente que conozco para detectar la mayoría de los errores, aislar la mayoría de los errores para la depuración y ganar confianza de que el código es bueno. Tienes que hacer esas cosas de todos modos , así que hazlas bien.

Telastyn
fuente
77
Sin embargo, creo que vale la pena señalar que es una habilidad adquirida. Veo que muchas personas escuchan la afirmación de que TDD realmente no es ni siquiera un adelanto de tiempo que se amortiza a largo plazo, es solo un período más rápido. luego lo prueban por un día y es doloroso porque tienen 0 experiencia, han leído 0 libros, no practican, solo esperan que funcione mágicamente. TDD no tiene ningún secreto que lo convierta en un mejor desarrollador, aún necesita practicar, pensar y tomar decisiones acertadas.
Sara
1
@kai - +1. Pasé semanas leyendo sobre TDD antes de probarlo. Leí todo lo que pude encontrar. Leo libros. Leí todos los blogs ágiles conocidos para obtener ejemplos. Leí xUnit Test Patterns de principio a fin. Durante las primeras semanas, todavía me llevó el doble de tiempo.
Jules
2
Estoy de acuerdo. TDD es difícil. La mentalidad es difícil. Cualquiera que diga "Solo escriba las pruebas primero" y afirme que es gratis no sabe cómo hacerlo. Se necesita práctica.
duffymo
@kai: por razones similares, muchas personas no pueden escribir con teclado. Lo intentaron una vez y después de una hora entera todavía no estaban escribiendo más rápido que antes ;-)
Steve Jessop
@SteveJessop Supongo que es una comparación bastante clara. O estar realmente no apto y salir a correr por 10 minutos, agotarse y preguntarse por qué no puede correr 10 millas en una hora. Realmente ilustra cómo debe trabajar antes de obtener los beneficios.
sara
4

La pregunta es, ¿qué diferencia de tiempo escribiría el código probado en la unidad sobre el código no probado, y cómo se escala esa diferencia de tiempo a medida que se amplía el alcance del proyecto?

El problema empeora a medida que aumenta la edad del proyecto: porque cada vez que agrega una nueva funcionalidad y / o cada vez que refactoriza la implementación existente, debe volver a probar lo que se probó anteriormente para asegurarse de que todavía funciona. Por lo tanto, para un proyecto de larga duración (de varios años), es posible que necesite no solo probar la funcionalidad sino volver a probarla 100 veces y más. Por esta razón, podría beneficiarse de tener pruebas automatizadas . Sin embargo, IMO es lo suficientemente bueno (o incluso mejor) si se trata de pruebas automatizadas del sistema, en lugar de pruebas unitarias automatizadas.

Un segundo problema es que los errores pueden ser más difíciles de encontrar y corregir si no se detectan temprano. Por ejemplo, si hay un error en el sistema y sé que funcionaba perfectamente antes de que hiciera su último cambio, entonces concentraré mi atención en su último cambio para ver cómo podría haber introducido el error. Pero si no sé si el sistema estaba funcionando antes de que hiciera su último cambio (porque el sistema no se probó correctamente antes de su último cambio), entonces el error podría estar en cualquier lugar.

Lo anterior se aplica especialmente al código profundo, y menos al código superficial, por ejemplo, agregar nuevas páginas web donde es poco probable que las páginas nuevas afecten a las existentes.

Como resultado, una cantidad considerable de errores escapan a la producción, que tengo que arreglar y, a su vez, retrasa mis otros proyectos.

En mi experiencia, eso sería inaceptable, por lo que estás haciendo la pregunta equivocada. En lugar de preguntar si las pruebas acelerarían el desarrollo, debería preguntarse qué haría que el desarrollo fuera más libre de errores.

Una mejor pregunta podría ser:

  • ¿Las pruebas unitarias son el tipo correcto de pruebas que necesita para evitar la "cantidad considerable de errores" que ha estado produciendo?
  • ¿Hay otros mecanismos de control de calidad / mejora (aparte de las pruebas unitarias) para recomendar también o en su lugar?

El aprendizaje es un proceso de dos etapas: aprende a hacerlo lo suficientemente bien, luego aprende a hacerlo más rápidamente.

ChrisW
fuente
3

Algunos aspectos a considerar, no mencionados en las otras respuestas.

  • Beneficio adicional / costo adicional depende de la experiencia con la escritura de pruebas unitarias
    • con mi primer proyecto de prueba unitaria, los costos adicionales se triplicaron porque tuve que aprender mucho y cometí muchos errores.
    • Después de 10 años de experiencia con tdd, necesito un 25% más de tiempo de codificación para escribir las pruebas por adelantado.
  • con más tdd-moduls todavía hay necesidad de prueba de gui manual y prueba de integración
  • tdd solo funciona cuando se hace desde el principio.
    • la aplicación de tdd a un proyecto existente y desarrollado es costoso / difícil. Pero puede implementar pruebas de regresión en su lugar.
  • Las pruebas automatizadas (pruebas unitarias y otro tipo de pruebas) requieren constantes de mantenimiento para que sigan funcionando.
    • haber creado la prueba mediante copiar y pegar puede hacer que el mantenimiento del código de prueba sea costoso.
    • Con una experiencia creciente, el código de prueba se vuelve más modular y más fácil de mantener.
  • Con una experiencia cada vez mayor, tendrá la sensación de que vale la pena crear pruebas automatizadas y cuándo no.
    • ejemplo, no hay un gran beneficio para unittest getters / setters / wrappers simples
    • no escribo pruebas automatizadas a través de la interfaz gráfica de usuario
    • me aseguro de que el businesslayer pueda ser probado

Resumen

Al comenzar con tdd, es difícil alcanzar el estado de "más beneficio que costo" siempre y cuando se encuentre en un "entorno de trabajo con limitaciones de tiempo", especialmente si hay "gerentes inteligentes" que le dicen que "se deshaga de lo costoso e inútil probando cosas "

Nota: con "pruebas unitarias" me refiero a "probar módulos en forma aislada".

Nota: con "prueba de regresión" quiero decir

  • escribe un código que produzca algún texto de salida.
  • escriba un código de "prueba de regresión" que verifique que el resultado de la generación sigue siendo el mismo.
  • la prueba de regresión le permite saber cada vez que cambia el resultado (que podría estar bien o un indicador de un nuevo error)
  • la idea de "prueba de regresión" es similar a las pruebas de aprobación
    • ... tomando una instantánea de los resultados y confirmando que no han cambiado.
k3b
fuente
Necesita revisión (¿el valor literario de las pruebas?)
JDługosz
3

Los programadores, como las personas que se ocupan de la mayoría de las tareas, subestiman el tiempo que realmente lleva completarlo. Con eso en mente, pasar 10 minutos para escribir una prueba puede considerarse como el tiempo que uno podría haber gastado escribiendo toneladas de código cuando en realidad, habría pasado ese tiempo creando el mismo nombre de función y parámetros que hizo durante la prueba . Este es un escenario TDD.

No escribir exámenes, es muy parecido a tener una tarjeta de crédito; Tendemos a gastar más o escribir más código. Más código tiene más errores.

En lugar de decidir tener una cobertura total de código o ninguna, sugiero centrarse en la parte crítica y complicada de su aplicación y hacer pruebas allí. En una aplicación bancaria, ese podría ser el cálculo de intereses. Una herramienta de diagnóstico del motor puede tener protocolos de calibración complejos. Si ha estado trabajando en un proyecto, probablemente sepa qué es y dónde están los errores.

Comience despacio. Desarrolla un poco de fluidez antes de juzgar. Siempre puedes parar.

JeffO
fuente
3

Ha habido una larga historia de la Junta de Programadores que promueve TDD y otras metodologías de prueba, no recordaré sus argumentos y estaré de acuerdo con ellos, pero aquí hay cosas adicionales a considerar que deberían matizar un poco:

  • Las pruebas no son igualmente convenientes y eficientes según el contexto. Desarrollo software web, dime si tienes un programa para probar toda la interfaz de usuario ... en este momento estoy programando macros de Excel, ¿realmente debería desarrollar un módulo de prueba en VBA?
  • Escribir y mantener el software de prueba es un trabajo real que cuenta a corto plazo (vale la pena a largo plazo). Escribir pruebas relevantes también es una experiencia para obtener
  • Trabajar en equipo y trabajar solo no tiene los mismos requisitos de prueba porque en el equipo debe validar, comprender y comunicar el código que no escribió.

Yo diría que la prueba es buena, pero asegúrese de hacer la prueba temprano y comprobar dónde está la ganancia.

Arthur Havlicek
fuente
1
"¿Realmente debería desarrollar un módulo de prueba para VBA?" Maldita sea, deberías. rubberduckvba.com/Features#unitTesting
RubberDuck
Hay algunas razones que no vamos a utilizar esto porque doen't satisfacer mis necesidades (estoy en pocas tareas días como máximo, entorno bloqueado, sucesor no se molestó en 3 partes). Buen comentario, el lenguaje no es una excusa en sí mismo :)
Arthur Havlicek
Todos los puntos justos @ArthurHavlicek.
RubberDuck
2
Escribir pruebas sigue siendo trivial en VBA. ¿Tiene todas las características elegantes que tienen algunos frameworks unittest? Eso es más difícil, pero ejecutar un programa llamado mainTest()que llama a todos los módulos de prueba no es realmente tan difícil.
enderland
1

Un beneficio a menudo ignorado de TDD es que las pruebas actúan como una protección para asegurarse de que no está introduciendo nuevos errores cuando realiza un cambio.

El enfoque TDD indudablemente consume más tiempo inicialmente, pero el punto final es que escribirás menos código, lo que significa menos cosas que saldrán mal. Todas esas campanas y silbidos que a menudo incluye como rutina no llegarán a la base del código.

Hay una escena en la película Swordfish en la que, si la memoria sirve, un pirata informático tiene que trabajar con una pistola en la cabeza y está erm ... de lo contrario distraído. El punto es que es mucho más fácil trabajar cuando su espacio de cabeza está en el código y tiene tiempo de su lado en lugar de meses en el futuro con un cliente gritándole y otras prioridades siendo exprimidas.

Los desarrolladores entienden que corregir errores más tarde es más costoso, pero le da la vuelta. Si se le pagara $ 500 por día para codificar cómo codifica ahora o $ 1000 si escribiera de forma TDD, podría morder la mano de la persona que le hace la segunda oferta. Cuanto antes deje de ver las pruebas como una tarea rutinaria y lo vea como un ahorro de dinero, mejor estará.

Robbie Dee
fuente
Esa cosa en su primera oración se llama Prueba de regresión
gato
0

Puedo relacionarme con su experiencia: nuestra base de código casi no tenía pruebas y era en su mayoría no comprobable. Literalmente llevó años desarrollar algo y corregir errores de producción tomó un tiempo precioso de las nuevas características.

Para una reescritura parcial, prometí escribir pruebas para todas las funciones principales. Al principio, me llevó mucho más tiempo y mi productividad sufrió notablemente, pero luego mi productividad fue mejor que nunca.

Parte de esa mejora fue que tenía menos errores de producción, lo que a su vez conducía a menos interrupciones -> Tenía un mejor enfoque en un momento dado.

Además, la capacidad de probar Y depurar el código de forma aislada realmente vale la pena: un conjunto de pruebas es muy superior a un sistema que no se puede depurar excepto con la configuración manual, por ejemplo, iniciar su aplicación y navegar a la pantalla y hacer algo ... tal vez unas pocas docenas de veces

Pero tenga en cuenta que hay una caída en la productividad al principio, así que comience a aprender las pruebas en algún proyecto donde la presión del tiempo aún no es una locura. Además, intente iniciarlo en un proyecto totalmente nuevo, el código heredado de pruebas unitarias es muy difícil y ayuda cuando sabe cómo se ve un buen conjunto de pruebas.

Christian Sauer
fuente
0

Solo para complementar las respuestas anteriores: recuerde que la prueba no es un propósito en sí mismo. El propósito de realizar pruebas es que su aplicación se comporte como se espera a través de la evolución, en contextos inesperados, etc.

Por lo tanto, escribir pruebas no significa probar todos los comportamientos de todos los puntos finales de una entidad. Es un error común. Muchos desarrolladores piensan que necesitan probar todas las funciones / objetos / métodos / propiedades / etc. Esto conduce a una alta carga de trabajo y un montón de código y pruebas irrelevantes. Este enfoque es común en grandes proyectos, donde la mayoría de los desarrolladores no son conscientes del comportamiento holístico, pero solo pueden ver su dominio de interacción.

El enfoque correcto cuando se trata de recursos y pruebas escasos es bastante obvio y de sentido común, pero no se formaliza comúnmente: invierta los recursos de desarrollo de pruebas primero en funcionalidades de alto nivel y descienda gradualmente a las especificidades . Esto significa que, en algún momento, como desarrollador solitario, no solo se centraría en las pruebas unitarias, sino también en funcional / integración / etc. probando y dependiendo de sus recursos de tiempo, gradualmente en las principales funciones unitarias, como planificaría y consideraría. Las pruebas de alto nivel proporcionarán la información necesaria para abordar las pruebas de bajo nivel / unitarias y para planificar su estrategia de desarrollo de pruebas de acuerdo con los recursos que tiene.

Por ejemplo, le gustaría probar una cadena de procesamiento primero como una caja negra. Si encuentra que algún miembro de la cadena falla debido a que el comportamiento no consideró una condición extrema, escriba las pruebas que garanticen la funcionalidad no solo en este miembro sino también en otros. Entonces entregas. Para el siguiente ciclo, detecta que a veces la red falla. Entonces escribe pruebas que abordan ese problema en los módulos que podrían ser vulnerables. Y así.

RodolfoAP
fuente