Pruebas automáticas de complementos de AutoCAD con Claude Code: sin mouse, desde dentro

Resumen

Conclusiones

• Para que Claude pruebe un programa de escritorio, no le des el mouse: dale una forma de ejecutar código dentro y de leer el estado. Así hizo 244 pruebas de AutoCAD 2027 en dos días; la persona solo intervino para dar permisos.
• La pieza que más rinde es un runner dentro del programa: 2,2 s de editar a ver el resultado, frente a 11–14 s reiniciando AutoCAD.
• Claude acierta con el lenguaje y falla con el entorno. Las barreras útiles son comprobaciones baratas y automáticas.

Lo clave

• El orden de las herramientas: primero, código dentro del programa. Después, mensajes de Win32 a una ventana y, si no alcanza, UI Automation. El mouse y el teclado reales quedan para el final, y solo con permiso.
• Leer el estado, no la pantalla: cuentas de entidades, variables de AutoCAD y archivos testigo. Las capturas, para confirmar.
• Los diálogos modales son el enemigo número uno: bloquean el runner, COM y hasta el arranque. Un aviso tuvo 180 s parado un arranque. Hace falta un vigilante de ventanas en cada prueba.
• Instancias propias: solo se termina lo que se arrancó. Windows reutiliza los PID: uno anotado como AutoCAD ya era Chrome.
• Los errores de Claude: barras invertidas en rutas, suponer comandos que no existen (VBASAVE, 4 intentos) y dar un PDF por bueno sin mirarlo.
• Hot Reload de Visual Studio no funciona con AutoCAD, ni automatizado ni a mano.

Recomendaciones

1. Construye un runner dentro del programa antes de escribir la primera prueba.
2. Inventaria la API el primer día y obliga a Claude a consultarla.
3. Trabaja en instancias propias y desechables, nunca en la sesión de la persona.
4. Pide los permisos de riesgo por tandas, con el alcance escrito. Usa el CLAUDE.md para pruebas de escritorio.
5. Exige una prueba de control para cada conclusión.

---

1. Qué siguió necesitando a una persona

• Instalar: el módulo VBA, el SDK de ObjectARX y el C++ de Visual Studio (los avisos de administrador de Windows).
• Crear la cuenta en la nube de Autodesk, porque puede costar dinero.
• Una primera pasada por las pruebas de interfaz (cinta, paletas, jigs), para validar qué se veía. Después se repitieron sin la persona.
• Dar permisos por tandas: mouse real, bajar la seguridad un rato, copiar el perfil, instalar.
• Una prueba de control a mano, la de Hot Reload (sección 6).
• Autorizar una prueba que el clasificador de permisos de Claude Code bloqueó con razón.

Todo lo demás lo hizo Claude: compilar, abrir y cerrar AutoCAD, ejecutar las pruebas, tumbarlo a propósito y recoger los restos, cerrar diálogos, depurar con breakpoints, mirar la pantalla y lanzar trabajos en la nube.

2. La infraestructura: un «Playwright» para AutoCAD

AutoCAD no tiene modo de pruebas, así que hay que construirlo:

1. Un runner dentro de AutoCAD. Es un complemento .NET cargado desde un bundle en ApplicationPlugins.
   • Escucha por un named pipe (<nombre>-<pid>) y pasa cada orden al hilo principal con el Dispatcher de WPF.
   • Carga cada prueba en un AssemblyLoadContext descargable, desde una copia sombra.
   • Trampa: AutoCAD retiene cada ensamblado en ExtensionLoader.m_extensions y no lo descarga. Con AssemblyLoadContext.All parecía descargarse; contando copias del ensamblado había 81. El runner ahora quita esa entrada.
2. Una herramienta de línea de comandos que compila, ejecuta una prueba en una instancia concreta y devuelve JSON. También repite la prueba cada vez que cambia la DLL y calcula las métricas de la IA.
3. Instancias propias registradas. Arranca acad.exe, espera al pipe y anota el PID. Solo termina lo que arrancó, y antes comprueba que el proceso siga siendo acad.exe.
4. Inventarios de la API (.NET por reflexión, COM desde los ensamblados de interop, LISP desde AutoCAD), con una regla: buscar cada símbolo antes de usarlo.
5. Un checklist con resultados, donde cada prueba lleva lo medido y su control.
6. Archivos de trabajo fuera del repositorio, para no ensuciarlo y para acotar las rutas de confianza.

El ciclo: 2,2 s de editar a ver el resultado; 3,7 s desde guardar, con dotnet watch; 11–14 s si hay que reiniciar AutoCAD.

3. Las herramientas, de mejor a peor

• Excelentes:
  • el runner con pipe;
  • los inventarios (0 funciones LISP inventadas);
  • las instancias propias;
  • una sonda de estado: entidades por tipo, CMDNAMES y las variables USERI1-5 y USERS1-2. Estas variables sirven de buzón: una rutina LISP, una macro VBA o un módulo C++ escribe ahí su resultado y el runner lo lee, así que vías muy distintas se comprueban con la misma prueba.
• Muy buenas:
  • testigos en archivo, para lo asíncrono y lo que muere sin avisar;
  • un lanzador de la consola con la entrada cerrada y tiempo límite;
  • mensajes de Win32 (BM_CLICK, WM_SETTEXT, WM_COMMAND) dirigidos a una ventana, para diálogos clásicos: el informe de error, la recuperación de dibujos y Guardar como. No tocan el mouse ni dependen del primer plano. Hay que mirar antes la clase del control: SysListView32 no es un ListBox;
  • la API REST de Design Automation.
• Buenas:
  • UI Automation, que falla con controles dibujados a mano: los botones de una cinta CUIx solo ofrecen Toggle;
  • SendStringToExecute, que no deja eco en el historial y encola de forma poco predecible;
  • capturas con PrintWindow, que detectaron cosas que las aserciones no veían, aunque bloquean al que llama si AutoCAD está ocupado;
  • Visual Studio controlado por DTE, para breakpoints sin la persona;
  • un cliente DAP propio para depurar LISP;
  • COM desde Python;
  • subagentes para el trabajo que no necesita AutoCAD.
• Último recurso: SendInput, el mouse y el teclado reales.
• Poco fiable: leer el historial de la línea de comandos con WM_GETTEXT, que da texto viejo o mezclado.
• No funcionaron:
  • el Hot Reload de Visual Studio;
  • Application.Quit(), que cuelga AutoCAD. SendStringToExecute("_.QUIT ") lo cierra limpio.

4. Las técnicas que hacen confiable el resultado

• Cada afirmación lleva su control. El fallo de /al en la consola no era la seguridad por sí sola, sino dos condiciones juntas. Una prueba pasó de «no se puede» a «funciona» cuando apareció la causa real.
• El estado antes que la pantalla. El resultado de una prueba se decide leyendo el dibujo o un testigo, no una captura.
• Lo peligroso, en instancias desechables. Así se provocaron las 5 caídas de AutoCAD sin miedo. El informe de error se cierra sin enviar (WM_CLOSE) y el diálogo de recuperación se contesta en el siguiente arranque.
• Un vigilante de diálogos. Lista las ventanas del proceso mientras corre cada prueba. Conviene conocer las variables que deciden si sale un diálogo: FILEDIA, CMDDIA, EXPERT, PROXYNOTICE y SECURELOAD.
• Lo que abre un diálogo se lanza en segundo plano, y el diálogo se contesta desde fuera. Así se midió qué hace cada respuesta del aviso de seguridad.
• Los permisos, por tandas y sin extenderlos solos a la tanda siguiente.

5. Dónde se equivoca Claude

• Barras invertidas en rutas de Windows, al pasar por heredocs o cadenas de Python. Fue el error más repetido. Se evita escribiendo el archivo con el editor o usando /.
• Herramientas propias mal usadas: compilar el proyecto equivocado por el orden de los argumentos, o lanzar la consola sin el lanzador (se colgó dos veces). Se evita haciendo que cada herramienta valide sus argumentos.
• Suponer que algo existe: VBASAVE costó 4 intentos. Con (getcname "_NOMBRE") se comprueba en un segundo.
• Dar por bueno sin mirar: un PDF aceptado sin revisar su contenido. Ahora se convierte en imagen y se revisa.
• Usar el teclado real una vez sin permiso. Quedó registrado como error.

El patrón: acierta con el lenguaje y falla con el entorno. Lo que lo frena son comprobaciones baratas y automáticas, como inventarios, getcname, validar argumentos y pruebas de control.

6. Hot Reload y la vista previa de XAML

El Hot Reload de Visual Studio falló cuatro veces automatizado, con el mismo error. Para descartar que el problema fuera la automatización, se repitió a mano: mismo error, «Hot Reload is not supported in this session». .NET lo permitiría dentro de AutoCAD; quien se niega es Visual Studio. La alternativa es el cargador propio del runner.

En la misma sesión aparece algo útil: la vista previa dinámica de XAML. La interfaz de AutoCAD 2027 está hecha en WPF, así que Visual Studio muestra en vivo su árbol de botones, paneles y pestañas, como el «inspeccionar elemento» de un navegador, y deja cambiar propiedades al vuelo. Funciona con cualquier programa en WPF, como Revit o Civil 3D, y no con los que están hechos en C++ puro o en Qt.

Cómo se midió y qué no

• Probado en AutoCAD 2027 (R26.0, build 26.0.118), con Windows 11 y Claude Opus 5.5 en Claude Code: 244 pruebas en dos días. Los resultados técnicos están en el post de AutoCAD 2027.
• Sin cifra: cuánto más confiable es esto frente a una prueba manual. Es un juicio, apoyado en los controles.
• Idea sin probar: las mismas técnicas deberían servir para otros programas de escritorio, incluso sin API. Por ejemplo, llenar datos, pulsar «Calcular» y anotar el resultado miles de veces, para tener un examen contra el cual reescribir el programa.

Material de libre uso

• CLAUDE.md para pruebas de escritorio: permisos, instancias, orden de herramientas y controles.
• pulsar-boton.py: pulsa un botón de un diálogo con un mensaje de Win32, sin mover el mouse, y solo si el proceso es el esperado.
• Informe de las pruebas sin intervención: la arquitectura, las 19 herramientas, las técnicas, los errores de la IA y las 16 recomendaciones.