Anteriormente, Joseph Morgan ha analizado en detalle la idea de las pruebas unitarias en JMP. Algunas lecturas excelentes:
Para simplificar las cosas en este blog, uso la terminología de Whittaker (2000) para definir las pruebas unitarias.
Pruebas unitarias: dominio de entrada
El término “prueba unitaria” significa probar componentes de software individuales o un conjunto de componentes. Los evaluadores definen el dominio de entrada para las unidades en cuestión e ignoran el resto del sistema.
Centrémonos en la segunda parte, donde los evaluadores definen el dominio de entrada. ¿Qué sucede si tenemos una función que queremos probar, pero queremos tratar los argumentos individuales como unidades?
Por ejemplo, tomemos la función de distribución beta de JSL (captura de pantalla del índice de secuencias de comandos). La función de distribución beta se utiliza para modelar variables aleatorias que están limitadas entre 0 y 1, y se utiliza a menudo en las estadísticas bayesianas.
Podríamos fijar alfa y beta en algo así como 0,5 y probar varios valores diferentes de q.
alpha = 0.5;
beta = 0.5;
Beta Distribution( 0.5, alpha, beta );
Beta Distribution( -1, alpha, beta );
Beta Distribution( 0, alpha, beta );
Ahora bien, determinar qué esperamos de cada llamada a la función Distribución Beta es un tema aparte (conocido como el problema del oráculo). Sin embargo, suponiendo que sabemos qué esperamos (en este caso, 0,5, un valor faltante y 0), podemos probar q. De esta manera, cada una de las entradas se puede comprobar de forma individual, como alfa, beta e incluso theta y sigma.
Prueba de un factor a la vez (OFAT)
¿Qué significa si nos centramos en un argumento a la vez? Al establecer los demás argumentos en un valor fijo (como el valor predeterminado) y cambiar el valor de un argumento, parece que estamos haciendo una prueba mediante OFAT.
Cuando se presentan los experimentos diseñados (típicos), analizamos las desventajas de OFAT. En particular, OFAT no se recomienda debido a las ineficiencias con los recursos y la falta de interacciones. Podemos ver que este enfoque de prueba tiene los mismos problemas. Sin embargo, si estamos probando software, podemos reutilizar estos casos de prueba más tarde, por lo que crear estas pruebas y determinar los resultados esperados no son necesariamente un desperdicio de recursos de prueba. Si encontramos un problema (es decir, el resultado no es el esperado), sabemos qué entrada se modificó que causó el problema. Esto es especialmente útil si se hace como parte de un proceso de desarrollo de aplicaciones, donde estas pruebas se pueden ejecutar de forma regular (de nuevo, un tema para un blog futuro).
¿Hacia dónde vamos desde aquí?
Si lees este blog y te preguntaste por qué no cambiaríamos más de una entrada a la vez, ten la seguridad de que lo haremos. De hecho, en los próximos blogs se hablará sobre cómo tratar este desafío de prueba como un problema de diseño de experimentos. ¡No te lo pierdas!
Whittaker, JA, 2000. ¿Qué es la prueba de software? ¿Y por qué es tan difícil?. IEEE software , 17 (1), pp.70-79.
