Pruebas unitarias apropiadas para programas cortos

Question

No soy novato desde que estoy programando de forma intermitente desde 1983, pero solo tengo experiencia real con lenguajes de scripting como Applescript, ARexx, HyperTalk y Bash.

Escribo scripts para automatizar el ingreso de datos, procesar imágenes por lotes y convertir formatos de archivo. Me dedico a Processing, Ruby y Python.

La mayoría de los programas que escribo tienen menos de 200 líneas con un máximo de 10 funciones. Deseo escribir programas más grandes y más capaces en el futuro. Quiero mejorar mis prácticas para evitar crear problemas frágiles e inmanejables. Los entornos de programación en los que trabajo (Script Editor.app y Text Wrangler.app) no son compatibles con las pruebas automatizadas.

En la escala que estoy trabajando ahora y escribir el código de procedimiento (no OO), es apropiado escribir unidad de prueba, que entiendo que son:

programas cortos a pruebe las funciones individuales de antes de combinarlas en un programa más grande que funcione completamente .

Se pruebas unitarias pena en comparación con su costo la hora de hacer programas en esta escala?

Answer 1

Definitivamente beneficioso como la escritura de las pruebas puede ayudar a verificar el diseño de sus funciones (la API tiene sentido) y ayuda a protegerlo de errores en el futuro. Las pruebas unitarias también pueden actuar como un contrato para sus funciones que pueden indicar cómo se deben usar las funciones y qué esperan.

Con programas más cortos que son claros simplemente leyendo el código, puede que no sea beneficioso probarlo exhaustivamente si no tienes mucho tiempo. De lo contrario, tengo que estar de acuerdo con mis colegas aquí en que las pruebas unitarias tienen una variedad de beneficios y son útiles incluso para proyectos pequeños.

Advertencia: es posible que los siguientes enlaces no sean aplicables, pero la explicación que se puede encontrar a continuación es buena lectura.

Recientemente se ha debatido en la blogósfera sobre cuándo es apropiado realizar pruebas, específicamente Test Driven Development (TDD).Es posible que desee comprobar algunos de los artículos tales como thesethreearticles por Roy Osherove.

Answer 2

Si el código lógicamente es divisible en unidades más pequeñas, entonces las pruebas unitarias son apropiadas. Si el código no se puede dividir con sensatez en componentes más pequeños, entonces es una sola unidad, y yo diría que en ese caso las pruebas unitarias automatizadas y las pruebas funcionales automatizadas serían indistinguibles.

Answer 3

totalmente, usted sabe que no está violando ninguna características existentes al tiempo que añade otros nuevos en un par de meses ....

sólo uno de los plus-valor de tener un conjunto de pruebas para un muchos pieza de código.

Answer 4

Sí. Cualquier cosa más larga que cero líneas puede ser probada en una unidad, generalmente con buenos resultados.

Answer 5

Me gustaría ver la probabilidad de regresiones, no el número de líneas de código. Si sus programas vivirán mucho tiempo y es probable que se modifiquen o se modifiquen, la prueba unitaria puede tener sentido. Si el código es desechable o no es probable que se modifique, entonces las pruebas unitarias probablemente no valgan la pena.

Answer 6

La única vez que necesita escribir pruebas unitarias es cuando le importa que la salida de su programa sea correcta y seguirá siendo correcta en el futuro.

Si la corrección de su código no es importante, entonces no es necesario probar la unidad.

Answer 7

Las pruebas unitarias sirven para un par de propósitos; lo más obvio es probar el código para determinar que está haciendo lo que se supone que debe hacer. Pero uno de los otros propósitos más útiles es documentación implícita; Si pruebas explícitamente una pieza de código para un comportamiento específico, queda claro que ese comportamiento se anticipa, incluso si no es obvio.

Considere el operador de adición humilde. Straightforward, ¿verdad? Bueno, ¿cuál es el comportamiento esperado al agregar dos enteros con signo, que son> mayores que MAXINT/2? ¿Es MAXINT o es un número negativo?

La documentación de todo esto puede ser difícil de manejar, a veces; no decir que no se debe hacer, pero la experiencia demuestra que con frecuencia no se hace. Sin embargo, una prueba unitaria explícita que prueba que el caso anterior sea negativo elimina todas las dudas; además de cumplir un propósito válido para la regresión, el comportamiento no ha cambiado con el tiempo.

Answer 8

Hoy es un proyecto pequeño, mañana será la pieza central de su infraestructura corporativa. Comience bien, obtenga una cobertura de código del 100% de inmediato.

Answer 9

Debo hacer una digresión con la mayoría de las respuestas. Donald Knuth dijo una vez en una entrevista que las personas tienden a probar la mayoría de las cosas cuando no están seguras de lo que están haciendo o están trabajando en un ámbito no tan cómodo.

Con esto en mente, digo que además de documentar como mcwafflestixlivejournalcom, las pruebas unitarias solo te ayudan si no estás 100% seguro de tu código. Tomando el ejemplo del operador de suma para dos entradas, no me importa el desbordamiento si agrego las edades de dos personas.

OTOH, la unidad de pruebas te hace factorizar la lógica central de tus programas (lo que te hace hacer cosas más modulares) y te ayuda a probar más rápido de lo que podrías hacer si estuvieras probando 'manualmente'. No todos somos Donald Knuth después de todo.

tener en cuenta que mi respuesta es para la funcionalidad pequeño, como el cartel original pidió