What Do Contribution Guidelines Say About Software Testing?

Immagina i progetti di software open-source come enormi e frenetici laboratori di cucina comunitaria. Chiunque può entrare, prendere un coltello e iniziare a tagliare le verdure (scrivere codice) per aiutare a cucinare un pasto migliore. Ma per far sì che la cucina funzioni senza intoppi, gli chef capo (i manutentori del progetto) lasciano un Libretto delle Regole sul bancone. Questo Libretto dice ai nuovi aiutanti come lavarsi le mani, dove trovare gli ingredienti e come consegnare le proprie verdure tagliate senza rovinare la zuppa.

Questo documento è come un team di ricercatori che è entrato in 200 di queste famose cucine comunitarie (specificamente quelle che utilizzano i linguaggi Python e JavaScript) per leggere i Libretti delle Regole e vedere cosa dicono effettivamente riguardo ai test.

Nel mondo della cucina, il "testing" è come assaggiare il piatto prima di servirlo per assicurarsi che non sappia di sapone. I ricercatori volevano sapere: I Libretti delle Regole insegnano davvero ai nuovi aiutanti come assaggiare il cibo, o danno semplicemente per scontato che tutti sappiano già come farlo?

Ecco cosa hanno scoperto, suddiviso in modo semplice:

1. La maggior parte delle cucine ha una sezione "Assaggio" (ma non tutte)

I ricercatori hanno scoperto che il 78% delle cucine aveva una sezione specifica nel proprio Libretto dedicata all'assaggio (il testing).

• Dove si trova? La maggior parte delle volte (58%), si trova in un file chiamato letteralmente "CONTRIBUTING" (il manuale di istruzioni principale). A volte è in una brochure separata e più ricercata (documentazione esterna), e raramente è solo scarabocchiata sul menu principale (README).
• Il vuoto: Circa il 22% delle cucine non aveva alcuna istruzione sull'assaggio. Se fossi entrato in quelle cucine, avresti dovuto indovinare come controllare se il tuo cibo fosse buono.

2. Lo squilibrio del "Come fare": Eseguire vs Scrivere

Quando i Libretti delle Regole parlavano di assaggio, erano molto bravi in una cosa ma scarsi in un'altra.

• Il "Come eseguire" (83,5%): La maggior parte dei Libretti diceva chiaramente: "Ecco l'incantesimo magico (comando) per assaggiare l'intera pentola". È come dire: "Premi questo pulsante per controllare il sapore".
• Il "Come scrivere" (37%): Molto meno Libretti spiegavano come creare effettivamente un nuovo test di assaggio. È come dire: "Premi il pulsante", ma non insegnarti come fabbricare un nuovo cucchiaio o come capire cosa sia un sapore "cattivo".
• Il risultato: Gli aiutanti sanno come controllare il cibo esistente, ma spesso restano a indovinare su come creare i propri test per i nuovi ingredienti che hanno aggiunto.

3. Il problema della "Piramide dei Test"

Nel software, esistono diversi livelli di testing, come diversi tipi di test di assaggio:

• Unit Tests (71%): Questi sono come assaggiare un singolo ingrediente (es. "Questa carota è dolce?"). I Libretti ne parlavano molto.
• Integration Tests (20,5%): Questi sono come assaggiare come la carota e la cipolla lavorano insieme nella pentola. I Libretti ne parlavano raramente.
• End-to-End Tests (15,5%): Questo è come assaggiare il pasto finale, completamente cucinato, per vedere se l'intero piatto funziona. I Libretti quasi mai ne parlavano.

La metafora: Gli chef sono molto preoccupati che le carote abbiano il sapore giusto, ma raramente dicono agli aiutanti come controllare se l'intero stufato sta per bruciare o se i sapori si mescolano bene.

4. Le "Armi Segrete" mancanti

I ricercatori hanno anche cercato consigli di cucina avanzati che rendono il testing più facile e affidabile:

• Mocking (9,5%): A volte, non puoi assaggiare l'acqua di mare reale nella tua zuppa; devi usare un saliera finta per simularla. Questo è chiamato "mocking". Solo 1 cucina su 10 aveva istruzioni su come usare questi strumenti finti.
• Coverage (25,5%): Questo è un punteggio che mostra quanto della ricetta è stato effettivamente assaggiato. Solo circa un quarto delle cucine diceva agli aiutanti quale punteggio dovevano puntare a raggiungere.
• Best Practices (9%): Consigli generali come "Assaggia sempre prima di servire" erano molto rari.

In sintesi

Il documento conclude che, sebbene la maggior parte dei progetti open-source voglia che i propri aiutanti testino il loro lavoro, le istruzioni che lasciano dietro di sé sono sbilanciate.

Sono bravi nel dire: "Ecco come si esegue il test", ma sono spesso silenziosi su:

• Come scrivere un nuovo test.
• Come testare interazioni complesse (integrazione).
• Come testare l'intero sistema (end-to-end).
• Come usare strumenti avanzati (mocking) o impostare obiettivi di qualità (coverage).

Il punto chiave: Se sei un nuovo aiutante in una di queste cucine, potresti sapere come premere il pulsante "assaggia", ma potresti ritrovarti da solo a dover capire come creare effettivamente un test di assaggio per la tua nuova ricetta, o come assicurarti che il tuo nuovo piatto non rovini l'intero pasto. Gli autori suggeriscono che i leader di progetto debbano scrivere istruzioni più chiare e complete, affinché gli aiutanti non debbano procedere per tentativi ed errori.