Asesoramiento de prueba de unidad en un objeto con muchas propiedades

Question

Soy bastante nuevo en las pruebas unitarias pero tengo la idea de probar unidades de código individuales que realizan una tarea específica y comprobable, sin embargo, estoy en una posición en la que necesita escribir pruebas y proporcionar confianza en la precisión de una salida de un método que actúa sobre un objeto con más de 50 propiedades. Las combinaciones de los valores de estas propiedades producen un resultado basado en reglas inyectadas desde un objeto de definición de regla (usando expresiones lambda) que esencialmente equivale a un porcentaje. Estos porcentajes de salida son "críticos para la misión" y han sido probados con cierta holgazanería, por ejemplo, la calidad de la clase de definición de regla (todos los porcentajes atribuibles para cada regla se suman al 100%) pero las propiedades reales del objeto no tienen estado.

El objeto "datos" proviene de una base de datos pero puedo, por supuesto, simularlo. Mi problema es el número de permutaciones de datos que necesitarían burla y la cantidad de pruebas que deberían escribirse para garantizar que los datos x, y, z (multiplicados por 50 exponenciales impares) se sientan casi imposibles.

Entonces, la pregunta es, ¿cómo se pueden verificar estas situaciones en un sentido real? ¿Las pruebas de scripting se basan en un estado "correcto" conocido y los resultados "correctos" son posibles/razonables? ¿Son aplicables las pruebas unitarias en este caso y, en caso negativo, qué alternativas existen?

Por cierto, este es el código heredado aquí con una pequeña oportunidad para refactorizar, pero solo si puedo garantizar la precisión, etc. dentro de los plazos de un par de días para hacer tanto el refactor como las pruebas.

Answer 1

creo que has dado la mitad de su respuesta a sí mismo:

Las combinaciones de los valores de estas propiedades producen una salida basado en reglas inyectada de un objeto de definición de la regla (usando expresiones lambda ) que esencialmente equivale a un porcentaje.

En la prueba de la unidad actual, sería burlarse tanto los datos como la regla. Por lo tanto, solo necesita asegurarse de que los métodos de entrada y salida se comporten correctamente.

Probar la regla es una tarea diferente. Solo puedo adivinar, pero generalmente, tendrá una tabla de Excel, o algo así, de posibles valores de entrada y salida para especificar los requisitos para esta regla. Convertiría esa misma tabla en un formato legible (csv) y la usaría directamente para conducir la prueba unitaria de la regla.

Answer 2

Bueno, no sé en qué idioma estás trabajando, pero después de mirar en tu perfil, creo que .Net podría estar involucrado.

Si estoy de acuerdo con esto, sugeriría utilizar pruebas controladas por datos. MSDN proporciona un corto de inicio rápido, que me ayudó mucho a los dados en: How to: Create a Data-Driven Unit Test Desde que leí este artículo startetd de inventar una nueva variante a utilizar en cada nuevo proyecto ...

trabajar con estos DDT en Visual Studio le permite almacenar sus datos de prueba en XML, CSV o en una tabla de base de datos. Tal vez es posible que escriba algún código para generar los valores necesarios para insertar en las pruebas.

Un segundo consejo sería el proyecto Pex and Moles de Microsoft que analiza su sistema bajo prueba y sobre esta base genera automáticamente datos de prueba para encontrar casos de prueba más extremos.

Answer 3

Si es la gran cantidad de combinaciones lo que está frenando al intentar generar cajas de prueba, puede echar un vistazo a all-pair probando.

Hemos usado PICT de microsoft para reducir al mínimo con éxito la cantidad de cajas de prueba y, al mismo tiempo, tener una confianza razonable para cubrir la mayoría de los casos.

Resumen

Por ejemplo, si desea crear un banco de pruebas para la partición y la creación del volumen, el dominio puede ser descrita por el parámetros siguientes: tipo, tamaño, sistema de archivo, el formato método, tamaño del clúster y Compresión. Cada parámetro tiene un número limitado de valores posibles, , cada uno de los cuales está determinado por su naturaleza (por ejemplo, Compresión solo puede estar Activado o Desactivado) o como una partición de equivalencia (como Tamaño).

Tipo: Primario, lógico, individual, Span, raya, Espejo, Tamaño RAID-5
: 10, 100, 500, 1000, 5000, 10000, 40000
método Formato: rápido, lento
sistema Archivo : FAT, FAT32, NTFS
tamaño Cluster: 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536
compresión: encendido, apagado

Hay más de 4.700 posibles combinaciones de estos valores. Sería ser muy difícil de probar todos ellos en un tiempo razonable. La investigación muestra que probar todos los pares de valores posibles proporciona muy buena cobertura y el número de casos de prueba seguirá siendo manejable. Para el ejemplo , {Primary, FAT} es un par y {10, slow} es otro; un solo caso de prueba puede cubrir muchos pares.

Para el conjunto de parámetros que se muestra arriba, PICT producirá 60 casos de prueba .

puntos para llevar

• hay más de 4700 combinaciones posibles
• PICT producirá 60 casos de prueba

todos los pares de

El razonamiento detrás de la prueba de todos los pares es esto: los errores más simples en un programa generalmente se desencadenan mediante un parámetro de entrada única .

La siguiente categoría más simple de errores consiste en los que dependen de las interacciones entre pares de parámetros, que pueden ser capturados con las pruebas de todos los pares.

Insectos que implican interacciones entre tres o más parámetros son progresivamente menos común, mientras que al mismo tiempo ser progresivamente más caro para encontrar por exhaustiva pruebas, que tiene como límite el prueba exhaustiva de todas las posibles entradas.