Test E2E "in un click": come TRestConfigDlg verifica backend e frontend generati

Quando un tool genera codice — API REST, backend, frontend — la vera domanda non è "il generatore ha prodotto dei file?" ma "quei file funzionano davvero?". Nel wizard API REST questa domanda trova risposta in una funzionalità integrata di test end-to-end, azionabile con un solo click direttamente dalla terza pagina del wizard, quella dedicata al log di generazione.

L'idea di fondo è semplice: dopo aver generato il progetto, l'utente può premere un pulsante e vedere, in tempo reale, l'esito di una suite di test che compila, avvia e interroga realmente il backend (e opzionalmente il frontend) appena creato — senza uscire dall'IDE del wizard.

Due pulsanti, due suite

Nella pagina 3 del dialog compaiono due pulsanti dedicati:

▶ Backend E2E — compila e avvia il backend Node.js/Express generato, quindi lo bombarda con richieste HTTP reali verso gli endpoint REST prodotti dal generatore.
▶ Frontend E2E — esegue il type-check Vue (vue-tsc), la build Vite del frontend e infine una suite Playwright headless che simula l'interazione di un utente reale con l'interfaccia generata.

Entrambi i pulsanti restano disabilitati finché non è stata completata con successo una generazione , e funzionano solo se il backend prodotto è di tipo Node.js + Express: gli altri backend non sono ancora coperti da questa infrastruttura di test.

Il flusso del test di backend

Il gestore orchestra l'intero processo:

Verifiche preliminari: la generazione dev'essere andata a buon fine, il backend dev'essere Node/Express, Node.js dev'essere reperibile nel PATH (o in una delle posizioni tipiche di installazione su Windows), e lo script run-e2e.mjs dev'essere individuabile — accanto all'eseguibile, in una cartella superiore, oppure tramite la variabile d'ambiente RESTGEN_E2E_DIR.
Costruzione della command line: il dialog traduce la configurazione scelta dall'utente (driver database, modalità di autenticazione) nel linguaggio atteso dallo script di test — ad esempio jwt/basic/none per l'autenticazione, oppure sqlite/pg/mssql/mysql/firebird per il dialetto SQL.
Una scelta pragmatica su Firebird: se il progetto usa Firebird, il test non si connette a un server Firebird reale, ma usa SQLite in locale (il modulo nativo node:sqlite, zero configurazione). Questo evita di trascinarsi dietro le note incompatibilità di wireCrypt/SRP della libreria node-firebird. Chi vuole davvero testare contro Firebird può comunque lanciare run-e2e.mjs a mano con --db firebird.
Avvio in background: il comando (node + script + parametri) parte su un thread Win32 separato, per non bloccare l'interfaccia.
Feedback in tempo reale: mentre il processo gira, l'output di npm install, compilazione TypeScript, avvio del server e chiamate HTTP scorre riga per riga nella memo di log del dialog.
Riepilogo finale: a processo concluso, viene letto un report JSON con il conteggio di test passati, falliti e con warning, mostrato come riga di riepilogo insieme al percorso del file.

Il thread worker: niente lambda, solo Win32 puro

Uno degli aspetti più interessanti dal punto di vista implementativo è la scelta di non usare TThread, TTask o lambda catturanti, ma un thread Win32 "grezzo" creato con CreateThread. Il commento nel codice è esplicito: bcc32c (il compilatore Clang-based di C++Builder) può confondersi con lambda annidate che catturano membri di classe all'interno di metodi. Per eliminare ogni ambiguità, i parametri necessari al thread vengono impacchettati in una struct semplice (TE2EParams) passata per puntatore:

cpp

struct TE2EParams {
    TButton*  btnRef;
    TLabel*   lbRef;
    TMemo*    memoRef;
    bool*     flagRef;
    wchar_t   rptPath[MAX_PATH];
    wchar_t   cmdLine[4096];
};

Il thread worker (E2EThreadProc) fa tre cose in sequenza:

Lancia il processo (node run-e2e.mjs ...) con CreateProcessW, reindirizzando stdout e stderr su una pipe anonima creata con CreatePipe.
Legge lo stream di output a blocchi da 4 KB, ricostruendo le righe complete (gestendo anche frammenti di riga a cavallo tra due letture) e le inoltra alla UI.
Al termine, tenta di leggere un report JSON dal percorso concordato, estraendo in modo leggero (senza un vero parser JSON, con una ricerca di sottostringa) i contatori pass/fail/warn.

Comunicare con la UI senza rischi di race condition

Aggiornare controlli VCL da un thread che non è quello principale è una delle fonti più comuni di crash nelle applicazioni Windows. Il dialog risolve il problema con due tecniche complementari, entrambe thread-safe per costruzione:

SendMessageW con EM_REPLACESEL per appendere ogni riga di log alla memo: un trucco classico che sfrutta il fatto che i messaggi di finestra vengono comunque processati nel thread proprietario del controllo.
PostMessageW con messaggi custom (WM_USER+100 per il riepilogo finale, WM_USER+101 per riabilitare il pulsante) per notificare in modo asincrono la conclusione del test, senza bloccare il thread di lavoro in attesa che la UI elabori l'evento.

Il flag booleano che segnala "test in corso" (E2ERunning / FERunning) viene riportato a false direttamente dal thread worker: trattandosi di una singola scrittura di un bool, l'operazione è atomica sia su x86 sia su x64, quindi non serve una sezione critica dedicata.

Un piccolo TTimer (tmrCursor) fa da watchdog: controlla ogni 300 ms se uno dei due flag è ancora attivo e, quando entrambi tornano a false, ripristina il cursore di sistema da clessidra a normale.

Il test del frontend: stessa infrastruttura, contenuto diverso

OnRunFEClick segue la stessa logica del test di backend ma orchestra una pipeline diversa: vue-tsc per il controllo dei tipi TypeScript/Vue, build di produzione con Vite, e infine una suite Playwright headless che simula interazioni utente reali contro il frontend appena costruito, collegato al backend Node generato in precedenza. Il riuso è quasi totale: la stessa struct TE2EParams e la stessa E2EThreadProc vengono impiegate per lanciare ed monitorare anche questo secondo processo, cambiando solo lo script (run-e2e-frontend.mjs) e i percorsi coinvolti (cartella frontend e backend_node).

Perché questo approccio ha senso

Al di là dei dettagli implementativi, la scelta progettuale merita una menzione: invece di limitarsi a generare codice e sperare che funzioni, il wizard chiude il cerchio offrendo una verifica automatica e visibile, integrata nello stesso strumento che ha generato il codice. L'utente non deve aprire un terminale, ricordarsi comandi npm, o installare Playwright a mano: preme un pulsante e osserva, riga dopo riga, se l'API generata risponde correttamente alle richieste reali — autenticazione inclusa, dialetto SQL incluso.

Dal punto di vista ingegneristico, la parte più istruttiva è probabilmente la gestione della concorrenza: un caso di scuola di come far convivere un processo esterno di lunga durata, uno streaming di output in tempo reale e un'interfaccia VCL reattiva, il tutto senza framework di threading di alto livello — solo primitive Win32 usate con disciplina.

#plyxSQL #SoftwareDevelopment #Sicurezza #CPlusPlusBuilder #Delphi #NodeJS #DPAPI #DevSecOps

venerdì 3 luglio 2026

Free PlyxSQL© SQL Beta - 1.0.0.60 Test E2E backend e frontend