Creación de prueba de unidad de automatización

¿Cuáles son algunas estrategias que podrían usarse para automatizar la creación de casos de prueba unitaria? ¿Qué aspectos necesitaría observar en cada clase para poder generar al menos un esqueleto de caso de prueba decente?

Me doy cuenta de que una solución automática integral no es práctica, pero me gustaría acelerar un poco la creación de la prueba al crear un esqueleto. No busco ejemplos de código, solo algunas sugerencias sobre dónde comenzar o ejemplos de cómo se ha hecho algo como esto para poder ver cómo lo abordaron y qué podría ser posible.

Estoy particularmente interesado en los métodos para crear esqueletos de pruebas unitarias en PHP, que no proporcionan todas las herramientas que ofrecen otros lenguajes, como sugerencias de tipo completo , por ejemplo.

Su estrategia y esqueleto dependen, no trivialmente, de qué tipo de pruebas está buscando generar, qué tipo de cobertura está buscando y el idioma / entorno en el que está trabajando.

Es bastante sencillo escribir un generador de prueba que, para lenguajes como C o Java, lea firmas de clase y genere automáticamente pruebas para casos de esquina estándar (pasando 0, 2 valores aleatorios, MAX_INT, MIN_INT, a un argumento entero, nulos para valores nulos , etc ...). Luego puede ejecutar las pruebas generadas, registrar los resultados de cada prueba y filtrarlas manualmente para eliminar las irrelevantes, aprobar resultados aceptables para las pruebas que pasan (para que puedan pasar automáticamente a partir de ese momento) y marcar como inválidas las que fallan .

Puede aumentar esto con el etiquetado / comentario / refactorización de clases para ayudar a su generador con sugerencias adicionales. Es posible que tenga una etiqueta que enumere todas las posibles excepciones que una llamada al método puede generar, o que proporciona un rango reducido de enteros válidos para un argumento entero. Míralos como una abreviatura para tener que escribir las pruebas tú mismo.

Entonces, aquí hay algunos componentes que querrás ver:

• Un componente para analizar automáticamente el código fuente / firmas de funciones / anotaciones manuales, produciendo casos de prueba estándar, o contornos / firmas para casos de prueba que esperan a que se complete su entrada.
• Un lenguaje en constante crecimiento / cambio de etiquetas / anotaciones / comentarios que puede ir a cualquier nivel de granularidad (método / clase / firma / bucles while / etc.) que representan sugerencias para el creador de pruebas automatizado. Idealmente, debería poder jugar con este lenguaje sin tener que recodificar su marco o cualquier fragmento en él.
• Corredor de prueba automatizado, con la capacidad de identificar pruebas nuevas / antiguas y registrar / probar contra respuestas "aceptables" para cada prueba. Idealmente, este corredor construirá una base de datos de ejecuciones de prueba, resultados aceptados / rechazados y resultados aceptables actuales para cada prueba.
• "Faker de objetos" automatizado que, dado un nombre de clase y un mapa de nombres-> valores, puede generar un objeto que imita la clase, devolviendo datos personalizables para llamadas a funciones, accesos, espacios de datos públicos, etc.

Existen muchos marcos de prueba que ya incluyen fragmentos de esta funcionalidad para varios idiomas y plataformas. Si bien es bastante fácil comenzar a hacer este trabajo usted mismo y desarrollar este tipo de marco de manera orgánica internamente, también es un proyecto interminable a largo plazo que probablemente duplicará el trabajo existente. Recomiendo tomarse un tiempo considerable para ver qué hay disponible primero, y luego decidir si vale la pena sumergirse.

Todavía no he tenido la oportunidad de usarlo en una aplicación de tamaño o complejidad significativa, pero existen herramientas, incluido CodePro AnalytiX de Google , que automatizan la generación de pruebas unitarias para aplicaciones Java . También encontré un producto comercial, la prueba C ++ de Parasoft , que parece permitir la generación de pruebas unitarias de C ++

Estas aplicaciones utilizaron la heurística para generar casos de prueba. No estoy seguro de que haya un solo marco que pueda usar para producir un esqueleto, pero hay construcciones que puede buscar. Tiendo a centrarme en los bucles, las declaraciones condicionales ( ifbloques, switch/ casedeclaraciones) y las excepciones, y creo casos de prueba que obligan a llevar a cabo diferentes rutas de ejecución.

No me enfocaría en acelerar la redacción de pruebas tratando de crear un esqueleto o plantilla, sino mejorando el análisis de la especificación y / o implementación y escribiendo pruebas de alta calidad. Ser capaz de identificar qué pruebas agregan el mayor valor temprano, escribirlas y luego completar los agujeros más tarde tendría un mayor impacto en la productividad y la calidad.

Solo para proporcionar más publicidad, Falcon probó CodePro en un proyecto y escribió un pequeño comentario sobre sus experiencias .

Hace unos años escribí un generador para acelerar las pruebas unitarias para un proyecto .NET. Había una gran base de código sin pruebas unitarias y tenía como objetivo aumentar rápidamente la cobertura básica. Aquí hay algunas notas que pueden ser de ayuda:

• Mi oportunidad fue que el marco central sobre el cual se desarrolló el proyecto proporcionó operaciones estándar y nombres de clases. Si está pensando en escribir el suyo, una estructura estándar como esta será de gran ayuda.
• El uso data-driven testingayuda mucho, si su base de código lo permite. El marco de prueba creó una tabla de base de datos para cada prueba unitaria para almacenar datos de prueba, de modo que cada fila en esa tabla era una prueba separada y no se requería ningún código adicional ( Regla de representación ). A partir de este momento, las pruebas reales podrían crearse fácilmente de forma automática o ingresarse manualmente.
• Las pruebas unitarias resultantes fueron simples pero sirvieron como smoke tests al menos. Para áreas de mayor riesgo, se escribieron pruebas manuales adicionales.

Para resumir, estoy de acuerdo en que una solución genérica sería poco práctica (si es posible). Creo que las posibilidades son mejores si la base de código es adecuada para la generación de pruebas y el marco de prueba puede aprovechar su estructura.

(Como nota al margen, hay Pex , pero es para .NET)