Ogni Task viene testato automaticamente prima di poter essere integrato con il merge — sia con test unitari mirati sia con test end-to-end più ampi che mettono alla prova l'app in esecuzione. La vista Testing mostra i test di un progetto indipendentemente da ogni singolo Task.

Testing

I test nel dettaglio del Task

Nella vista di dettaglio di un Task, il passo Test mostra l'esito dei test unitari del progetto (quanti superati, quanti falliti e l'output di eventuali errori) e il passo E2E mostra l'esito degli scenari end-to-end — azioni utente simulate nell'applicazione effettivamente in esecuzione. Se Test o E2E falliscono, al passo Fix vengono passati i dettagli dell'errore; esso tenta di correggere il problema e i test vengono rieseguiti; ciò può ripetersi automaticamente alcune volte. Se i test continuano a fallire dopo i tentativi consentiti, il Task passa a failed e i dettagli dell'errore restano associati ad esso.

La vista Testing e le sue schede

Per impostazione predefinita la vista Testing ha tre schede interne: History — Dashboard, History — Modules e Unit Tests. Altre schede — Setup, Dashboard, Verdicts, E2E Plans, Scenarios, Integration Tests, Release Tests e l'E2E Cockpit — esistono ma restano nascoste finché non vengono attivate nella personalizzazione della navigazione.

La scheda Unit Tests

La scheda Unit Tests contiene un pulsante Run unit tests, i totali dell'ultima esecuzione (superati, falliti, saltati), una tabella Run History (data, superati, falliti, totale, durata) e, a destra, i singoli test dell'esecuzione selezionata con filtri come Passed e Failed. Facendo clic su un'esecuzione in Run History se ne elencano i test; filtrando su Failed si legge l'errore di ogni test fallito. Un'esecuzione che non si è conclusa è contrassegnata come crashed con il motivo e un pulsante Ask AI to fix.

Verdetti di Verify

Dopo i test, il passo Verify ricontrolla ciascun criterio di accettazione del Task e registra uno di tre verdetti:

• passed — il controllo è stato eseguito e corrisponde a quanto atteso.
• failed — il controllo è stato eseguito ma non corrisponde; l'output indica cosa è stato eseguito, cosa era atteso e cosa è stato restituito.
• unverifiable — il controllo non ha potuto essere eseguito affatto (ad esempio richiede un'istanza in esecuzione non disponibile). Questo non fa mai fallire il Task; la voce viene elencata come in attesa di verifica manuale.

Build & Start/Stop

Consente di avviare una build del progetto e poi di avviare o fermare un'istanza in esecuzione su una propria porta dedicata — indipendente dalle istanze isolate che la Pipeline avvia per i test E2E durante un Task.

Stato in tempo reale e output del terminale

Si vede a colpo d'occhio se l'istanza è in esecuzione, in fase di build o ferma, e si può seguire in diretta il suo output del terminale/console — utile per confermare che una build sia riuscita o per capire perché non lo è.

Interruzione di un'esecuzione di test

Una suite di test unitari di lunga durata può essere interrotta in qualsiasi momento direttamente dalla vista Testing, senza attenderne il termine. Se il server AITM viene riavviato mentre è in corso un'esecuzione di test, questa viene interrotta in modo sicuro — non resterà bloccata nello stato "running" al successivo avvio; il server la rileva e la ripulisce.

Budget combinato di CPU/RAM per i test

I test unitari e i test E2E condividono un unico budget complessivo di CPU e memoria che si adatta automaticamente alle dimensioni del server su cui gira AITM. I test vengono eseguiti in sequenza in modo che il loro uso combinato di risorse non sovraccarichi mai l'host — ciò protegge dai crash causati dall'esecuzione simultanea di più carichi di test.

Cronologia dei verdetti E2E

Ogni esecuzione di test end-to-end registrata per questo progetto viene conservata nella scheda Verdicts (nascosta per impostazione predefinita), con il relativo verdetto (pass, feature bug, environment error, ecc.) e una linea temporale che si può far scorrere all'indietro per vedere come è evoluto nel tempo lo stato di salute dei test.

Menu a discesa dell'indicatore dei bug

Il menu a discesa dell'indicatore dei bug nella barra superiore mostra al massimo i 10 bug più recenti, mantenendosi veloce e leggibile anche nei progetti con una lunga cronologia di bug. Mostra sempre un collegamento Open Bug Section — anche quando l'elenco delle voci recenti è vuoto — così il menu non porta mai a un vicolo cieco; l'elenco completo dei bug è sempre a un clic, indipendentemente da quante voci recenti esistano.