Negli ultimi 10 mesi, gli sviluppatori di edX hanno lavorato duramente per aumentare la copertura dei test automatizzati. I nostri 2,491 unit test Python attualmente coprono l'87% delle righe nel repository edx-platform. Questi test, insieme ai nostri test di accettazione Selenium e agli unit test JavaScript, vengono eseguiti su ogni richiesta pull, consentendoci di convalidare rapidamente le modifiche al codice proposte.
Come abbiamo aumentato la copertura dei test da meno del 50% all'87% in soli 10 mesi? Parte della risposta è uno strumento chiamato copertina del differenziale.
In un flusso di lavoro tipico, uno sviluppatore che lavora in un progetto di grandi dimensioni potrebbe effettuare una richiesta pull che modifica alcune dozzine di righe di codice. Prima della modifica, la copertura del test poteva essere del 72%; in seguito, potrebbe essere ancora del 72%. La dimensione del progetto rende difficile vedere l'effetto di una singola richiesta pull. Diff-cover ti consente di concentrarti sulle metriche di qualità di una singola richiesta pull anziché sul progetto nel suo insieme.
Diff-cover misura le righe di codice in un git diff. Per una proposta di modifica al codice, ti mostrerà quali delle righe modificate mancano di copertura. Questa è un'idea semplice, ma ha potenti implicazioni:
- Per gli sviluppatori, diff-cover fornisce una metrica chiara e realizzabile: se tocchi una riga di codice, dovrebbe essere coperta.
- Per i revisori del codice, diff-cover semplifica la verifica che gli sviluppatori stiano scrivendo test per tutte le modifiche al codice.
Concentrandosi sulla copertura differenziale, gli sviluppatori possono compiere piccoli passi visibili per migliorare la copertura globale. Un determinato commit potrebbe aumentare globale copertura solo di una frazione di percento ma hanno ancora il 95% diff copertura. Lentamente ma inesorabilmente, mentre gli sviluppatori scrivevano i test per le modifiche al codice, anche la copertura globale iniziò ad aumentare. Di conseguenza, siamo stati in grado di rilevare alcuni tipi di bug prima.
Ancora più importante, altri sviluppatori hanno iniziato a contribuire alla copertura delle differenze e ad assumere la proprietà dello strumento. Ad esempio, Cale ha generalizzato lo strumento per supportare ulteriori controlli di "qualità" e Sarina lo ha esteso per segnalare le violazioni di pep8 e Pylint in una differenza. Molti altri sviluppatori hanno fornito feedback e suggerimenti durante un beta test iniziale di Diff-Cover. Lo strumento è diventato un punto di partenza per un riesame dei nostri standard di revisione e test del codice, che ha portato a un vero cambiamento nella nostra cultura dei test.
Naturalmente, la misurazione della copertura presenta ancora alcune limitazioni importanti. In particolare, la copertura del differenziale elevato lo fa non è un garantire un codice privo di bug: in un sistema strettamente accoppiato, una modifica a un componente potrebbe avere conseguenze di vasta portata e indesiderate su altre parti del sistema, anche se il codice modificato è coperto al 100%. In questi casi, i test di integrazione possono rilevare bug che potrebbero non essere rilevati dagli unit test.
Se pensi che la copertina del differenziale possa esserti utile, dai un'occhiata al progetto: è open source e disponibili su GitHub. Il codice è progettato per essere estensibile ad altri sistemi di controllo della versione e controlli di qualità, quindi sentiti libero di aggiungere funzionalità e fare una richiesta pull!
Will Daly è un ingegnere di test presso edX. Quando non sostiene lo sviluppo basato su test o l'ottimizzazione di un cluster Jenkins, gli piace correre lungo i fiumi e ridurre al minimo il numero di cose nel suo appartamento.
