Automazione dei test
Un add-in per AutoCAD e BricsCAD, due versioni per ciascun programma, una nuova ogni anno: chi verifica tutto a mano a un certo punto testa solo ciò che ha modificato per ultimo. Gli errori arrivano allora da dove nessuno ha guardato. Gli add-in CAD si possono testare automaticamente – solo non con un unico strumento.
Tre livelli, tre strumenti
Un'auto nuova passa sul banco prova prima di arrivare al cliente. I freni li misura una macchina, non l'ingegnere, e allo stesso modo per ogni auto. Per un add-in questa verifica si suddivide su tre livelli:
| Livello | Con che cosa | Che cosa viene verificato | Limite |
|---|---|---|---|
| Logica senza CAD | normale programma di test .NET | regole, calcoli, testi | nemmeno un tipo CAD |
| Comandi e database | console di AutoCAD accoreconsole.exe |
comandi, transazioni, disegni | nessuna interfaccia |
| Interfaccia | strumento di test come TesteriX | finestre di dialogo, barra multifunzione, area di disegno | più lento, più oneroso |
Ogni livello è più veloce ed economico del successivo. Testi quindi il più possibile in basso. Il livello più basso ha un effetto collaterale: un progetto di test che include solo i file sorgente privi di CAD non si compila più non appena un tipo AutoCAD scivola nella logica. Veglia quindi sulla separazione degli strati.
Il livello intermedio: AutoCAD senza finestra
La console di AutoCAD è AutoCAD senza interfaccia: database, riga di comando, LISP e .NET ci sono, e si avvia in pochi secondi. Esegue uno script e poi si chiude. Un comando di test nell'add-in crea per ogni caso un disegno nuovo in memoria, verifica e alla fine scrive una riga che uno script può cercare:
[CommandMethod("TesteRichtlinie")]
public void TesteRichtlinie()
{
var editor = Application.DocumentManager.MdiActiveDocument.Editor;
var fehler = 0;
try
{
// Disegno nuovo in memoria: dotazione di base 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)
{
// Un'eccezione non gestita chiuderebbe la console
editor.WriteMessage("\nFEHLER Ausnahme: " + ex.Message);
fehler++;
}
// Lo script di test cerca questa riga nel log
editor.WriteMessage($"\nTESTERGEBNIS: {fehler} FEHLER");
}
La console viene richiamata con disegno e 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)
Che cosa abbiamo imparato testando gli esempi per il libro «AutoCAD .NET API»:
- Gli script senza BOM AutoCAD li legge come ANSI. In UTF-8 le lettere accentate diventano caratteri illeggibili.
- Un comando sconosciuto, basta un errore di battitura, termina l'intero script senza messaggio di errore.
- Un'eccezione non gestita chiude la console. Per questo i comandi di test intercettano tutto da sé.
- Se nello script manca un input, la console attende all'infinito. Lo script chiamante ha bisogno di un limite di tempo.
SECURELOADfinisce nel profilo del registro e vale poi anche per il normale AutoCAD. Se lo script si interrompe prima, il valore non viene mai ripristinato. Più pulito è un profilo proprio o un utente Windows dedicato ai test.
Con l'opzione /readonly la stessa console verifica intere cartelle piene di disegni dei clienti, senza modificarli. Se nel log manca la riga «TESTERGEBNIS», è successo qualcosa di peggio di una violazione delle regole: un file danneggiato o un timeout. Per BricsCAD la guida di Bricsys indica le opzioni di avvio /b per uno script e /automation per un BricsCAD con finestra principale nascosta. Lo script deve allora chiudere il programma da sé.
Test di apprendimento: che cosa si aspetta il Suo codice da AutoCAD
Alcuni test non verificano il Suo codice, ma il comportamento del programma CAD su cui il Suo codice fa affidamento. Un metodo genera un'eccezione con un determinato valore? Un nuovo disegno arriva con o senza il layer Defpoints? Se ciò cambia con la versione successiva, deve segnalarlo un test, non un utente. E tali test vanno eseguiti nell'ambiente in cui il comportamento si manifesta: un test in un disegno in memoria non si comporta in ogni punto come lo stesso codice nel disegno attivo. Ce lo ha mostrato un test di apprendimento diventato rosso proprio per questo motivo.
Il livello superiore: interfaccia e area di disegno
Finestre di dialogo e barra multifunzione nella console non esistono. Qui lavora il nostro strumento di test TesteriX. Per l'area di disegno rinuncia volutamente a registrare i clic del mouse, perché ciò influenzerebbe troppo gli add-in. Al loro posto la controlla tramite comandi CAD tratti dal catalogo, ordinati per oggetto, layer e disegno. Un comando può restituire un valore, ad esempio l'ID di un nuovo cerchio o il numero dei layer. Questo valore finisce in una variabile, e un confronto lo verifica rispetto al valore atteso. Se un programma CAD avvia un ulteriore processo, come fanno le varianti OEM di AutoCAD e BricsCAD, TesteriX distingue il programma avviato dal processo effettivamente in esecuzione. Il nostro consiglio per la postazione di lavoro: due monitor, il CAD su uno, TesteriX sull'altro.
Errori tipici
- Testare tutto attraverso l'interfaccia. Ciò che si può verificare nella console va verificato lì.
- Mescolare logica e accessi CAD. Allora non si può più testare nulla senza CAD.
- Comandi di test senza
try/catchpropri. La prima eccezione termina l'intera esecuzione. - Script di test senza limite di tempo. Un comando in attesa blocca il server di build.
- Disattivare
SECURELOADnello script di test e lasciare il normale AutoCAD senza protezione. - Testare i disegni originali invece delle copie.
- Dopo un cambio di versione eseguire solo i propri test, senza avere test di apprendimento.
Come La aiutiamo
- Automazione dei test: predisponiamo test su tutti e tre i livelli per i Suoi add-in CAD o li consegniamo al Suo team: Automazione dei test.
- TesteriX: il nostro strumento di test per applicazioni desktop e CAD, TesteriX nel Cadida-Shop.
- Formazione: come realizzare add-in testabili fa parte del corso «AutoCAD .NET API con C#».
- Il Suo progetto: Fissi un primo colloquio.
Fonti: Ebi F. Eilber, AutoCAD .NET API (libro tecnico, uscita prevista nel 2027), capitolo «Test»; guida di TesteriX, capitoli «Particolarità CAD» e «Catalogo»; guida di Bricsys, «Startup options».
