CAD-Anwendungen automatisch testen: AutoCAD- und BricsCAD-Add-ins prüfen

Testautomatisierung

Ein Add-in für AutoCAD und BricsCAD, je zwei Programmversionen, jedes Jahr eine neue: Wer das von Hand prüft, testet irgendwann nur noch das, was er zuletzt geändert hat. Die Fehler kommen dann von dort, wo niemand hingesehen hat. CAD-Add-ins lassen sich automatisch testen – nur nicht mit einem einzigen Werkzeug.

Drei Ebenen, drei Werkzeuge

Ein neues Auto fährt auf den Prüfstand, bevor es zum Kunden kommt. Die Bremsen misst eine Maschine, nicht der Ingenieur, und zwar bei jedem Auto gleich. Bei einem Add-in teilt sich diese Prüfung auf drei Ebenen auf:

Jede Ebene ist schneller und billiger als die nächste. Testen Sie deshalb so viel wie möglich unten. Die unterste Ebene hat einen Nebeneffekt: Ein Testprojekt, das nur die CAD-freien Quelldateien einbindet, baut nicht mehr, sobald ein AutoCAD-Typ in die Logik rutscht. Es passt also auf die Schichten auf.

Die mittlere Ebene: AutoCAD ohne Fenster

Die AutoCAD-Konsole ist AutoCAD ohne Oberfläche: Datenbank, Kommandozeile, LISP und .NET sind da, gestartet ist sie in wenigen Sekunden. Sie arbeitet ein Skript ab und beendet sich danach. Ein Testbefehl im Add-in legt für jeden Fall eine frische Zeichnung im Speicher an, prüft und schreibt am Ende eine Zeile, nach der ein Skript suchen kann:

[CommandMethod("TesteRichtlinie")]
public void TesteRichtlinie()
{
    var editor = Application.DocumentManager.MdiActiveDocument.Editor;
    var fehler = 0;
    try
    {
        // Frische Zeichnung im Speicher: Grundausstattung ja, Dokument nein
        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)
    {
        // Eine unbehandelte Ausnahme würde die Konsole beenden
        editor.WriteMessage("\nFEHLER  Ausnahme: " + ex.Message);
        fehler++;
    }
    // Nach dieser Zeile sucht das Testskript im Protokoll
    editor.WriteMessage($"\nTESTERGEBNIS: {fehler} FEHLER");
}

Aufgerufen wird die Konsole mit Zeichnung und Skript:

"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)

Was wir beim Testen der Beispiele für das Buch „AutoCAD .NET API“ gelernt haben:

• Skripte ohne BOM liest AutoCAD als ANSI. In UTF-8 werden Umlaute zu Zeichensalat.
• Ein unbekannter Befehl, schon ein Tippfehler, beendet das ganze Skript ohne Fehlermeldung.
• Eine unbehandelte Ausnahme beendet die Konsole. Testbefehle fangen deshalb alles selbst.
• Fehlt im Skript eine Eingabe, wartet die Konsole ewig. Das aufrufende Skript braucht eine Zeitgrenze.
• SECURELOAD landet im Registry-Profil und gilt dann auch für das normale AutoCAD. Bricht das Skript vorher ab, wird der Wert nie zurückgesetzt. Sauberer ist ein eigenes Profil oder ein eigener Windows-Benutzer für Tests.

Mit dem Schalter /readonly prüft dieselbe Konsole ganze Ordner voller Kundenzeichnungen, ohne sie zu verändern. Fehlt die Zeile „TESTERGEBNIS“ im Protokoll, ist Schlimmeres passiert als ein Regelverstoß: eine kaputte Datei oder eine Zeitüberschreitung. Für BricsCAD nennt die Bricsys-Hilfe die Startschalter /b für ein Skript und /automation für ein BricsCAD mit verstecktem Hauptfenster. Das Skript muss das Programm dann selbst beenden.

Lerntests: Was sich Ihr Code von AutoCAD erwartet

Manche Tests prüfen nicht Ihren Code, sondern das Verhalten des CAD-Programms, auf das sich Ihr Code verlässt. Wirft eine Methode bei einem bestimmten Wert eine Ausnahme? Kommt eine neue Zeichnung mit oder ohne Layer Defpoints? Ändert sich das mit der nächsten Version, soll es ein Test melden, nicht ein Anwender. Und solche Tests gehören in die Umgebung, in der das Verhalten auftritt: Ein Test in einer Zeichnung im Speicher verhält sich nicht in jedem Punkt wie derselbe Code in der aktiven Zeichnung. Das hat uns ein Lerntest gezeigt, der genau deshalb rot wurde.

Die obere Ebene: Oberfläche und Zeichenfläche

Dialoge und Menüband gibt es in der Konsole nicht. Hier arbeitet unser Testwerkzeug TesteriX. Für die Zeichenfläche verzichtet es bewusst auf das Aufzeichnen von Mausklicks, weil das die Add-ins zu stark beeinflussen würde. Stattdessen steuert es sie über CAD-Befehle aus dem Katalog, geordnet nach Objekt, Layer und Zeichnung. Ein Befehl kann einen Wert zurückgeben, etwa die ID eines neuen Kreises oder die Zahl der Layer. Dieser Wert landet in einer Variablen, und ein Vergleich prüft ihn gegen den Sollwert. Startet ein CAD-Programm einen weiteren Prozess, wie es OEM-Varianten von AutoCAD und BricsCAD tun, unterscheidet TesteriX das gestartete Programm vom tatsächlich laufenden Prozess. Unsere Empfehlung für den Arbeitsplatz: zwei Monitore, CAD auf dem einen, TesteriX auf dem anderen.

Typische Fehler

• Alles über die Oberfläche testen. Was in der Konsole geprüft werden kann, gehört dorthin.
• Logik und CAD-Zugriffe vermischen. Dann lässt sich nichts mehr ohne CAD testen.
• Testbefehle ohne eigenen try/catch. Die erste Ausnahme beendet den ganzen Lauf.
• Testskripte ohne Zeitgrenze. Ein wartender Befehl blockiert den Build-Server.
• SECURELOAD im Testskript abschalten und das normale AutoCAD ungeschützt zurücklassen.
• Originalzeichnungen testen statt Kopien.
• Nach einem Versionswechsel nur die eigenen Tests laufen lassen, aber keine Lerntests haben.

Quellen: Ebi F. Eilber, AutoCAD .NET API (Fachbuch, erscheint voraussichtlich 2027), Kapitel „Test“; TesteriX-Hilfe, Kapitel „Besonderheiten CAD“ und „Katalog“; Bricsys-Hilfe, „Startup options“.