Automatización de pruebas
Un add-in para AutoCAD y BricsCAD, dos versiones de cada programa y una nueva cada año: quien lo revisa a mano acaba probando solo lo último que ha cambiado. Los errores llegan entonces de donde nadie ha mirado. Los add-ins de CAD se pueden probar automáticamente, pero no con una sola herramienta.
Tres niveles, tres herramientas
Un coche nuevo pasa por el banco de pruebas antes de llegar al cliente. Los frenos los mide una máquina, no el ingeniero, y de la misma forma en cada coche. En un add-in, esta prueba se reparte en tres niveles:
| Nivel | Con qué | Qué se prueba | Límite |
|---|---|---|---|
| Lógica sin CAD | programa de prueba .NET normal | reglas, cálculos, textos | ni un solo tipo de CAD |
| Comandos y base de datos | consola de AutoCAD accoreconsole.exe |
comandos, transacciones, dibujos | sin interfaz |
| Interfaz | herramienta de pruebas como TesteriX | diálogos, cinta de opciones, área de dibujo | más lento, más laborioso |
Cada nivel es más rápido y más barato que el siguiente. Por eso, pruebe todo lo posible en el nivel inferior. El nivel más bajo tiene un efecto secundario: un proyecto de prueba que solo incluye los archivos fuente sin CAD deja de compilar en cuanto un tipo de AutoCAD se cuela en la lógica. Es decir, vigila las capas.
El nivel intermedio: AutoCAD sin ventana
La consola de AutoCAD es AutoCAD sin interfaz: base de datos, línea de comandos, LISP y .NET están disponibles, y se inicia en pocos segundos. Ejecuta un script y después se cierra. Un comando de prueba en el add-in crea para cada caso un dibujo nuevo en memoria, comprueba y escribe al final una línea que un script puede buscar:
[CommandMethod("TesteRichtlinie")]
public void TesteRichtlinie()
{
var editor = Application.DocumentManager.MdiActiveDocument.Editor;
var fehler = 0;
try
{
// Dibujo nuevo en memoria: configuración básica sí, documento no
using (var db = new Database(true, true))
using (var tr = db.TransactionManager.StartTransaction())
{
ErzeugeLayer(tr, db, "A-WAND");
ErzeugeLayer(tr, db, "Möbel");
var falsch = Richtlinie.FindeFalscheLayer(tr, db);
if (falsch.Count != 1 || !falsch[0].StartsWith("Möbel"))
{
editor.WriteMessage("\nFEHLER Richtlinie: " + string.Join(", ", falsch));
fehler++;
}
tr.Commit();
}
}
catch (System.Exception ex)
{
// Una excepción no controlada cerraría la consola
editor.WriteMessage("\nFEHLER Ausnahme: " + ex.Message);
fehler++;
}
// El script de prueba busca esta línea en el protocolo
editor.WriteMessage($"\nTESTERGEBNIS: {fehler} FEHLER");
}
La consola se llama con un dibujo y un script:
"C:\Program Files\Autodesk\AutoCAD 2027\accoreconsole.exe" /i "C:\Tests\Leer.dwg" /s "C:\Tests\test.scr"
test.scr (ANSI, CRLF):
(setvar "SECURELOAD" 0)
_NETLOAD
"C:\Tests\MeinAddin.dll"
TesteRichtlinie
(setvar "SECURELOAD" 1)
Lo que aprendimos al probar los ejemplos del libro «AutoCAD .NET API»:
- AutoCAD lee los scripts sin BOM como ANSI. En UTF-8, los caracteres especiales se convierten en un galimatías.
- Un comando desconocido, basta una errata, termina todo el script sin mensaje de error.
- Una excepción no controlada cierra la consola. Por eso, los comandos de prueba lo capturan todo ellos mismos.
- Si falta una entrada en el script, la consola espera eternamente. El script que la llama necesita un límite de tiempo.
SECURELOADse guarda en el perfil del registro y se aplica entonces también al AutoCAD normal. Si el script se interrumpe antes, el valor nunca se restablece. Es más limpio usar un perfil propio o un usuario de Windows propio para las pruebas.
Con el modificador /readonly, la misma consola revisa carpetas enteras llenas de dibujos de clientes sin modificarlos. Si en el protocolo falta la línea «TESTERGEBNIS», ha ocurrido algo peor que una infracción de las reglas: un archivo dañado o un tiempo de espera agotado. Para BricsCAD, la ayuda de Bricsys menciona los modificadores de inicio /b para un script y /automation para un BricsCAD con la ventana principal oculta. En ese caso, el script debe cerrar el programa por sí mismo.
Pruebas de aprendizaje: lo que su código espera de AutoCAD
Algunas pruebas no comprueban su código, sino el comportamiento del programa CAD en el que confía su código. ¿Lanza un método una excepción con un valor determinado? ¿Se crea un dibujo nuevo con o sin la capa Defpoints? Si esto cambia con la siguiente versión, debe avisar una prueba, no un usuario. Y estas pruebas deben ejecutarse en el entorno en el que se produce el comportamiento: una prueba en un dibujo en memoria no se comporta en todos los aspectos igual que el mismo código en el dibujo activo. Nos lo demostró una prueba de aprendizaje que se puso en rojo precisamente por eso.
El nivel superior: interfaz y área de dibujo
En la consola no hay diálogos ni cinta de opciones. Aquí trabaja nuestra herramienta de pruebas TesteriX. Para el área de dibujo renuncia deliberadamente a grabar clics de ratón, porque eso influiría demasiado en los add-ins. En su lugar, la controla mediante comandos CAD del catálogo, ordenados por objeto, capa y dibujo. Un comando puede devolver un valor, por ejemplo el ID de un círculo nuevo o el número de capas. Este valor se guarda en una variable y una comparación lo contrasta con el valor esperado. Si un programa CAD inicia otro proceso, como hacen las variantes OEM de AutoCAD y BricsCAD, TesteriX distingue el programa iniciado del proceso que realmente se está ejecutando. Nuestra recomendación para el puesto de trabajo: dos monitores, CAD en uno y TesteriX en el otro.
Errores típicos
- Probarlo todo a través de la interfaz. Lo que se puede comprobar en la consola debe probarse allí.
- Mezclar la lógica y los accesos al CAD. Entonces ya no se puede probar nada sin CAD.
- Comandos de prueba sin
try/catchpropio. La primera excepción termina toda la ejecución. - Scripts de prueba sin límite de tiempo. Un comando que espera bloquea el servidor de compilación.
- Desactivar
SECURELOADen el script de prueba y dejar el AutoCAD normal sin protección. - Probar con dibujos originales en lugar de con copias.
- Tras un cambio de versión, ejecutar solo las pruebas propias, pero no tener pruebas de aprendizaje.
Cómo le ayudamos
- Automatización de pruebas: configuramos pruebas en los tres niveles para sus add-ins de CAD o se las traspasamos a su equipo: automatización de pruebas.
- TesteriX: nuestra herramienta de pruebas para aplicaciones de escritorio y CAD, TesteriX en la tienda de Cadida.
- Formación: cómo construir add-ins que se puedan probar forma parte de la formación «AutoCAD .NET API con C#».
- Su proyecto: Concierte una primera conversación.
Fuentes: Ebi F. Eilber, AutoCAD .NET API (libro técnico, publicación prevista para 2027), capítulo «Pruebas»; ayuda de TesteriX, capítulos «Particularidades de CAD» y «Catálogo»; ayuda de Bricsys, «Startup options».
