Agenti IA e testing: perché l'accelerazione del codice sposta il collo di bottiglia su requisiti, ambiente e standard

Primo run dopo la migrazione dei test Angular da Karma a Vitest: oltre mille errori TypeScript, nessun test eseguito. Sotto Karma gli stessi test passavano in Chrome. Con Angular 21, i nuovi progetti usano Vitest e, se non richiesto, girano in jsdom. La sostituzione dei tipi in tsconfig.spec.json ha sbloccato la compilazione, ma 52 spec poi sono caduti per API mancanti in jsdom. In Chromium passavano senza modifiche¹. Tesi: con agenti che accelerano la scrittura del codice, il collo di bottiglia si sposta su requisiti, design e test².

1. Tesi e contesto operativo

Agenti come Claude Code e Cursor portano in code review, in un giorno, lavoro che prima richiedeva settimane. La velocità sposta l’attenzione su requisiti e test. Le fasi restano, cambia dove serve precisione. Spingere ancora sulla generazione del codice dà rendimenti decrescenti². Il caso Angular mostra come un dettaglio di setup possa fermare una suite¹.

2. Caso pratico: la migrazione da Karma a Vitest in Angular 21

Müslüm Yılmaz ha migrato una base di test da Karma a Vitest. Primo run: oltre mille errori TypeScript, zero test eseguiti. Gli stessi test, sotto Karma, passavano in Chrome¹. Con Angular 21 i nuovi progetti usano Vitest per default. Se non richiesto, girano in jsdom¹. La guida di migrazione non citava i tipi. In tsconfig.spec.json restavano quelli di Jasmine. Sostituirli con "vitest/globals" ha rimosso la maggior parte degli errori di tipo e sbloccato la compilazione¹.

Dopo la compilazione, la suite ha avuto 88 fallimenti. Solo 14 hanno raggiunto una prima asserzione. Molti spec si fermavano prima¹. Di questi, 52 file fallivano per un’API non presente in jsdom. In Chromium passavano senza modifiche¹.

3. Diagnosi tecnica: cosa è andato storto e perché

La migrazione ha messo in evidenza tre aspetti.

Primo, i tipi. Tenere i tipi di Jasmine in un progetto passato a Vitest blocca la compilazione. La sostituzione con "vitest/globals" risolve gran parte degli errori e permette di eseguire i test¹.

Secondo, l’ambiente DOM. jsdom non replica tutte le API di un browser. Qui 52 spec si rompevano per metodi o oggetti non disponibili. Spostare gli stessi test su Chromium li faceva passare. La diagnosi ha seguito due domande per ogni file: è partito almeno un test? Lo stesso spec passa in un browser reale?¹

Terzo, i timer e l’asincrono. I test con fakeAsync sono rimasti rossi. La guida indica una patch di zones.js e suggerisce la riscrittura verso i fake timers di Vitest. I fix richiedono interventi distinti. Per evitare che il type check li ricompilasse, i file con mock problematici e gli spec rotti sono stati esclusi, non solo da angular.json ma anche da tsconfig.spec.json¹.

4. Il nodo più ampio: standard, governance e maturity del testing

Con agenti che accelerano lo sviluppo, ambiguità su requisiti e test diventano funzionalità finite, pronte per la review. Se l’input è confuso, l’output lo moltiplica. Il testing sale di grado. Un’intera feature può nascere da uno o due prompt. Il rischio è che nessuno la usi end to end fino a tardi. Il test diventa lo strumento per scoprire bug e scarti tra specifica e prodotto².

Sul fronte degli agenti, cresce la pressione sugli standard. L’Agentic AI Foundation conta 305 membri e, secondo il direttore esecutivo Mazin Gilbert, circa un’azienda nuova si iscrive ogni giorno lavorativo. AGNTCon + MCPCon North America ha registrato 4.300 iscritti, il doppio dell’evento di Amsterdam di inizio anno. Il 40% dei membri sono startup. Il 19% enti non profit, laboratori nazionali e istituzioni accademiche. “Se questa fondazione non si muove alla velocità della luce, diventa irrilevante.” “Questi protocolli sono l’aria che respiri. Sono l’impianto idraulico.” Senza basi solide, l’area degli agenti diventa “un pasticcio, costosa e proibitiva” per la scala³.

Simon Tomes, il 3 novembre 2026, propone un approccio diverso ai maturity model del testing. Punto centrale: consapevolezza. Un modello fornisce uno specchio, non un giudizio. Rende visibili pattern, punti di forza e aree dove il team resta reattivo. Ogni livello indica con quanta coerenza e intenzione si applicano le pratiche. Aiuta a scegliere il prossimo passo adatto al contesto, senza rincorrere l’ultimo trend⁴.

5. Implicazioni pratiche per team e QA

• Verificare l’ambiente. Eseguire gli spec in jsdom e in un browser reale per distinguere errori di setup da bug applicativi¹.
• Curare la configurazione di test. Aggiornare i tipi in tsconfig.spec.json a "vitest/globals". Quando necessario, escludere temporaneamente file rotti anche dal type check, non solo dall’esecuzione, per sbloccare la pipeline¹.
• Gestire l’asincrono in modo esplicito. Decidere se applicare una patch a zones.js o riscrivere verso i fake timers di Vitest¹.
• Collegare velocità e governance. Senza protocolli condivisi l’area degli agenti diventa “un pasticcio, costosa e proibitiva” per la scala³.
• Usare i maturity model come strumento di consapevolezza. Mappare pratiche attuali e scegliere un passo alla volta, adatto al proprio contesto⁴.

L’automazione aumenta il throughput. La qualità dipende dalla chiarezza dei requisiti, dalla coerenza dell’ambiente e dalle pratiche di test^1,2. In assenza di basi solide, come ricorda AAIF per i protocolli degli agenti, i costi emergono in fase di scala³.