Usa i test come prove

Parti dal requisito

I test forniscono prove per affermazioni specifiche. Un’esecuzione riuscita non dimostra ogni proprietà del software. Prima di chiedere test, individua il comportamento importante e il difetto che ogni verifica deve rilevare.

Per un’esportazione fittizia di dati di un’organizzazione, il requisito principale è l’isolamento dei dati. Un utente dell’organizzazione A non deve ricevere record dell’organizzazione B. Un test che verifica solo il download riuscito non dimostra questo requisito.

Chiedi all’agente di spiegare il legame tra requisito e asserzione. Diventa più facile individuare i casi mancanti prima che la suite di test cresca.

Scegli l’ambito di test adatto

Un test unitario può verificare rapidamente una piccola trasformazione. Un test di integrazione può verificare come collaborano i componenti. Un test end-to-end può verificare una sequenza importante per l’utente attraverso l’applicazione dopo il deployment o una sua istanza rappresentativa.

Usa l’ambito più ristretto che fornisce le prove necessarie. Un formattatore non richiede un test completo nel browser per ogni input. Un confine di autorizzazione può richiedere una route reale e il percorso di accesso ai dati. Un’interazione critica nel browser richiede prove sull’interfaccia renderizzata.

Nessuna percentuale fissa di tipi di test è adatta a ogni sistema. Scegli in base al guasto da rilevare e al costo di manutenzione della verifica.

Evita un’ipotesi errata condivisa

Un agente può scrivere implementazione e test partendo dallo stesso fraintendimento. I due possono concordare senza soddisfare il requisito.

Supponi che l’implementazione filtri i record con l’ID organizzazione fornito nella richiesta. Il test usa lo stesso ID per l’utente autenticato e per la richiesta. Il test passa. Manca il caso in cui un utente richiede l’ID di un’altra organizzazione.

Aggiungi quel caso usando il percorso reale di identità attendibile e autorizzazione. Un mock che restituisce sempre «consentito» non dimostra l’isolamento dei tenant. Dimostra solo il comportamento dopo un’autorizzazione riuscita.

Verifica che il test possa fallire

Per un difetto noto, esegui il nuovo test di regressione sulla versione difettosa in un branch isolato. Conferma che fallisca per il motivo previsto. Applica poi la correzione ed eseguilo di nuovo.

Un test che fallisce perché non riesce a caricare una fixture non fornisce ancora prove sul comportamento aziendale. Esamina il motivo del fallimento, non solo il codice di uscita.

Per modifiche più ampie, il mutation testing può aiutare a valutare se specifiche modifiche al codice fanno fallire i test. Ha un costo e non sostituisce la revisione dei requisiti. Usalo dove le prove aggiuntive aiutano una decisione con conseguenze rilevanti.

Mantieni le prove collegate alla modifica

Esegui le verifiche pertinenti sulla revisione finale. Registra quelle saltate e i motivi. Il risultato di un commit precedente potrebbe non valere dopo una correzione richiesta in revisione.

Mantieni i test comprensibili. Preferisci preparazione e asserzione esplicite a una grande funzione ausiliaria che nasconde la condizione importante. Rimuovi le verifiche ridondanti se aggiungono costi di manutenzione senza rilevare guasti diversi.

Il revisore deve poter dire cosa dimostrano i test e cosa resta incerto. Questa spiegazione è più utile di un numero elevato di test.