Test dal telefono, criteri di copertura compresi
Sei livelli di test, criteri di copertura dalle istruzioni a MC/DC e perché avere i risultati sul telefono è un vantaggio.
La scheda Progetto → Test non è solo un elenco di ciò che fallisce. È il posto dove commissioni i test, leggi la loro cronologia e dal caso che fallisce arrivi a ciò che in realtà verifica, e tutto dal telefono, senza una sola riga di prompt.
Livelli
I test sono divisi in sei livelli: unitari, di integrazione, di sistema, E2E, prestazioni dell'interfaccia e prestazioni del backend. Si cambiano in alto e ciascuno tiene la propria cronologia di Esecuzioni.
Quella divisione non è cosmetica. Un test unitario che fallisce significa altro rispetto a un E2E che fallisce, e quando li vedi entrambi in un unico elenco perdi proprio l'informazione per cui i livelli esistono.
Criteri di copertura — e perché, in fondo
Quando commissioni i test con la frase «scrivi dei test», ottieni dei test. La domanda è cosa verificano, e a questo nessuno ha una risposta finché qualcosa non cade in produzione.
Un criterio di copertura è una regola che dice quando i test sono abbastanza. Non è una percentuale; è una frase che si può verificare:
- Copertura delle istruzioni
- Ogni istruzione viene eseguita almeno una volta. Il più economico e il più debole: il codice è girato, ma sui suoi rami non dice niente.
- Copertura dei rami
- Ogni condizione risulta una volta vera e una volta falsa. Qui i test iniziano a trovare errori.
- MC/DC
- Per ogni sottocondizione si dimostra che da sola cambia il risultato. Costoso, ma con condizioni composte è l'unico modo per scoprire che una di esse è di troppo.
- Pair-wise
- Ogni coppia di valori di caratteristiche diverse si incontra in almeno un test. Una frazione delle combinazioni, la maggior parte degli errori.
Nell'applicazione scegli il criterio quando commissioni i test e ne vedi quanto è esigente, prima che l'Agente si metta al lavoro. È la differenza rispetto a «scrivi dei test»: sai cosa otterrai, e l'Agente sa quando fermarsi.
Il panorama dei criteri per il tuo progetto fattelo mettere insieme dall'Agente. Aggiungerà per ciascuno quanto è esigente proprio qui: per un parser è una cosa, per un modulo un'altra cosa.
Perché averlo sul telefono è un vantaggio
- I risultati si leggono anche senza connessione. Le Esecuzioni sono scaricate, quindi puoi frugarci dentro anche in aereo.
- Dal caso che fallisce parte un collegamento alla sua descrizione nella documentazione e a uno screenshot dell'istante della caduta. Non a cento righe di registro.
- La cronologia attraverso le Esecuzioni rivela un test instabile: quello che una volta passa e la volta dopo no. Nel terminale te lo ricordi, qui lo vedi.
- I valori misurati nei test di prestazioni hanno un andamento attraverso le Esecuzioni. Un numero solo non dice niente di una misura, la direzione sì.
- Commissionare altri test sono pochi tocchi, non la scrittura di un prompt. Si scelgono il livello e il criterio, il resto lo fa l'Agente.
Da dove vengono i risultati
L'applicazione legge JUnit XML, cioè il formato che quasi ogni strumento di test sa sputare fuori. L'Agente lo scrive nel progetto e il telefono lo scarica con lo specchio: nessun servizio in mezzo, nessun caricamento da nessuna parte.
La forma in cui i risultati vengono scritti la stabilisce uno skill applicativo. Gli skill si mettono nel progetto dalla scheda Progetto, sezione Skill applicativi; senza di essi vedrai soltanto quello che nel progetto c'è già.
Si è inceppato da qualche altra parte rispetto a quanto c'è qui? Scrivi a support@coden-app.com.