Test Behaviors, Not Methods! Detecting Tests Obsessed by Methods
Questo articolo propone un nuovo "test smell" chiamato "Test Obsessed by Method", che identifica i test che coprono molteplici percorsi di esecuzione di un singolo metodo di produzione, e ne valida il rilevamento attraverso uno studio empirico sulla libreria standard di Python, dimostrando che tali test spesso verificano comportamenti multipli e possono essere rifattorizzati in unità più focalizzate.
Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo
Immagina di essere uno chef che prepara un menu degustazione per un critico gastronomico. La regola d'oro della grande cucina è: servi un solo sapore distinto per ogni piatto. Se servi un unico piatto contenente una bistecca, una fetta di torta e una pallina di gelato tutti mescolati insieme, il critico si confonderà. Non saprà se la bistecca è poco cotta, se la torta è troppo dolce o se il gelato si sta sciogliendo. Se qualcosa va storto, non saprà a quale parte del pasto dare la colpa.
Nel mondo del software, i "piatti" sono i test, e i "sapori" sono i comportamenti (ciò che il software dovrebbe fare).
Questo articolo, intitolato "Test Behaviors, Not Methods!" (Testare i comportamenti, non i metodi!), sostiene che molti test software vengono attualmente serviti come quel piatto misto e disordinato. Gli autori, Andre Hora e Andy Zaidman, introducono un nuovo modo per individuare questi test confondenti, che chiamano "Test Ossessionati dai Metodi".
Ecco la suddivisione della loro scoperta utilizzando semplici analogie:
1. Il vecchio modo: Contare gli ingredienti
In precedenza, gli esperti cercavano di trovare questi test disordinati semplicemente contando quante volte un test "toccava" il codice. Pensavano: "Se un test chiama il codice di produzione 3 o più volte, probabilmente sta facendo troppo".
Gli autori chiamano questo odore di "Test Eager" (test impaziente). Tuttavia, hanno scoperto che questo metodo è come giudicare un pasto contando solo quanti cucchiai sono stati usati. È impreciso. Un test potrebbe chiamare una funzione molte volte solo per preparare la scena, senza testare effettivamente diversi sapori. È un modo goffo per trovare il problema.
2. La nuova idea: Guardare il film (Analisi del runtime)
Invece di limitarsi a contare i cucchiai, gli autori suggeriscono di guardare il film del test mentre viene riprodotto. Propongono una nuova regola: se un singolo test costringe un pezzo di codice a percorrere molteplici "strade" (percorsi) diverse per raggiungere il traguardo, quel test è "ossessionato".
Pensa a un metodo di produzione (un pezzo di codice) come a un labirinto.
- Buon Test: Invii un esploratore nel labirinto per controllare se la porta sinistra funziona. Poi invii un secondo esploratore per controllare se la porta destra funziona. Chiaro e focalizzato.
- Test Ossessionato: Invii un esploratore che attraversa la porta sinistra, poi torna indietro, attraversa la porta destra e poi prova il tunnel segreto, tutto in un colpo solo.
Gli autori chiamano questo "Test Ossessionato dal Metodo". Il test è "avido" perché cerca di coprire ogni possibile percorso di un singolo labirinto in un'unica soluzione, invece di dividere il lavoro.
3. L'esperimento: Controllare la libreria Python
Per vedere se questa "ossessione" è un problema reale, gli autori hanno intrapreso una caccia al tesoro attraverso la Libreria Standard di Python (una vasta collezione di codice pre-scritto usato da milioni di sviluppatori).
Hanno esaminato 2.054 test. Ecco cosa hanno scoperto:
- La Caccia: Hanno trovato 44 test che erano "ossessionati". Questi test stavano cercando di controllare più risultati diversi di una singola funzione in un colpo solo.
- La Diffusione: Questi test disordinati sono stati trovati in 11 delle 12 librerie diverse che hanno controllato. Non è un glitch raro; è un'abitudine comune.
- La Soluzione: In media, ciascuno di questi 44 test disordinati stava in realtà cercando di fare due lavori diversi. Se venissero divisi, quei 44 test potrebbero diventare 118 test puliti e focalizzati.
- Il Momento "Aha!": In circa il 23% di questi test disordinati, i programmatori avevano effettivamente scritto commenti che ammettevano: "Ehi, stiamo testando due cose diverse qui!". Sapevano che era disordinato, ma lo facevano comunque.
4. Perché questo è importante?
Gli autori sostengono che quando un test cerca di coprire troppi percorsi contemporaneamente:
- È difficile da capire: Come quel piatto misto, non puoi capire quale sapore stai gustando.
- È fragile: Se cambi il codice della "porta sinistra", potresti accidentalmente rompere il test della "porta destra", anche se non sono correlati.
- È difficile da riparare: Quando un test fallisce, non sai quale comportamento specifico si sia rotto.
In sintesi
L'articolo non pretende di risolvere ogni problema di testing. Invece, offre uno strumento più affilato (usando l'analisi del runtime invece di contare soltanto) per individuare i test che cercano di fare troppo con un singolo pezzo di codice.
Suggeriscono che se un test costringe una funzione a percorrere molteplici percorsi diversi, dovrebbe essere diviso. Proprio come uno chef dovrebbe servire la bistecca, la torta e il gelato su piatti separati, uno sviluppatore dovrebbe scrivere test separati per ogni comportamento distinto.
In breve: Non essere avido con i tuoi test. Testa un comportamento, un percorso, un sapore alla volta.
Sommerso dagli articoli nel tuo campo?
Ricevi digest giornalieri degli articoli più recenti corrispondenti alle tue parole chiave di ricerca — con riassunti tecnici, nella tua lingua.