Testa e copri il tuo codice oggi stesso!. Una guida pratica per aggiungere un… | di Itay Bittan | Dicembre 2023 | Intelligenza-Artificiale

Una guida pratica per aggiungere un’azione GitHub motivazionale al tuo repository

Inizierò con una confessione: come ingegnere del software, ho odiato ed evitato di scrivere test per anni. Mi sono imbattuto in così tanti progetti polverosi: alcuni senza alcun test, altri che prevedevano test ma non erano mai stati eseguiti come parte delle pipeline CI/CD, e gli ultimi includevano una copertura dei test davvero scarsa.

Da un lato, ci sono molte ragioni per cui dovremmo scrivere i test, ma dall’altro ci sono più scuse (o “giustificazioni”) per cui li saltiamo.

Pur mirando a diventare un professionista, sono sempre stato geloso di quei brillanti repository open source con copertura dei test al 100% e li sognavo nei miei repository quotidiani là fuori. Quattro anni fa, mentre lottavo con me stesso su questo argomento, ho scoperto coperchio del differenzialeun grande progetto open source con una missione semplice: copri il tuo Proprio cambiamenti con i test. Ecco come lo descrivono gli autori:

La copertura differenziale è la percentuale di linee nuove o modificate coperte dai test. Ciò fornisce uno standard chiaro e realizzabile per la revisione del codice: se tocchi una riga di codice, quella riga dovrebbe essere coperta. La copertura del codice è responsabilità di ogni sviluppatore!

In poche parole, diff-cover presuppone che tu stia utilizzando Idiota e l’esecuzione di uno strumento di copertura. Usando git è facile ottenerlo tuo numeri di linea modificati e confrontali con i numeri di linea scoperti del tuo strumento di copertura preferito. Quasi tutti gli strumenti di copertura possono produrre un formato XML unificato e generico, indipendentemente dal linguaggio del codice (Python, JavaScript, ecc.)

Per riassumere, il processo che ho svolto fino ad ora come parte del CI è stato:

1. Esegui tutti i test con uno strumento di copertura, utilizzando il file pytest E pytest-cov Pacchetti:

py.test -o junit_family=xunit2 --junitxml result.xml -xv --ff --cov-config=.coveragerc --cov=<my_package> --cov-report=xml --cov-report=term <tests_package>

(nota che creerà copertura.xml E risultato.xml file di report).

2. Eseguire lo strumento diff-cover utilizzando il file coperchio del differenziale pacchetto:

diff-cover coverage.xml --compare-branch=origin/master

che stamperà qualcosa di simile al seguente output:

-------------
Diff Coverage
Diff: origin/master...HEAD, staged and unstaged changes
-------------
my_package/connections/snowflake_client.py (100%)
my_package/logic/celery_tasks/top_score_task.py (100%)
my_package/queries/build_algorithm_studio_dataframes.py (100%)
-------------
Total:   16 lines
Missing: 0 lines
Coverage: 100%
-------------

Come puoi vedere dall’output sopra, ho apportato modifiche a 3 file diversi e ognuno di essi è completamente coperto (ho dovuto aggiungere alcuni nuovi test e altri test esistenti coprivano già alcune delle mie modifiche).

Vedere il rapporto Diff Coverage su ogni PR (Pull Request) ha reso tutti dipendenti dal raggiungimento di quel 100%. Vogliamo dimostrare che siamo responsabili dei nostri cambiamenti e che possiamo coprirli, invece di essere percepiti come perdenti e ottenere una percentuale bassa. Inoltre, come effetto collaterale, abbiamo sperimentato cambiamenti minori e incrementali nei PR, che è un altro la migliore pratica. Questo perché ora tutti ci pensano due volte prima di aggiungere righe di codice ridondanti.

Dopo aver utilizzato questa metodologia ormai da alcuni anni, vediamo un costante aumento delle percentuali di copertura complessiva dei nostri repository. Di conseguenza, c’è stato anche un aumento della stabilità della nostra produzione.

Nuova azione GitHub

Qualche mese fa, il mio talentuoso collega Asaf Gallea ha deciso di sfruttare questo successo in un modo più semplice ma allo stesso tempo più potente nuova azione GitHub. Questa azione applica la stessa idea di diff-cover e genera anche un report amichevole come commento nella tua richiesta di pull, fornendo collegamenti a righe scoperte nel caso in cui ti sia sfuggito qualcosa. La nuova azione consente inoltre di impostare una soglia di copertura minima (predefinita all’80%) — altrimenti, il controllo dello stato fallirà e non sarai in grado di unire le tue modifiche:

Nell’immagine sopra vediamo l’esempio del report GitHub Action. Esiste una soglia minima del 95%, in questa richiesta pull sono state modificate 20 righe, di cui 18 righe coperte dai test e due righe, 505–506, non coperte. Dato che abbiamo raggiunto solo il 90% di copertura per i file modificati, il controllo dello stato non è riuscito ed è impossibile unirli al ramo principale.

Tieni presente che questo rapporto non dice nulla sulla copertura totale del repository. Potrebbe essere basso (60%), eppure qualsiasi nuova modifica deve superare il 95%, quindi alla fine la copertura totale aumenterà.

Configura l’azione tests-coverage-report nel tuo repository

Questo è tutto! Ora aggiungiamo questa azione a tuo repository in pochi passaggi. Presumo che si tratti di un progetto Python ma puoi aggiungerlo anche a progetti in diversi linguaggi di programmazione.

Nella cartella principale del repository, crea il file .github/workflows cartelle se non esiste ancora. Ora, all’interno del workflows cartella creiamo un nuovo file chiamato test.yml con il seguente contenuto:

# This workflow will install Python dependencies, run tests check the coverage
name: Test with coverage
on:
pull_request:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-python@v3
with:
python-version: 3.10
- name: Install Dependencies
run: |
python -m pip install --upgrade pip
pip install pytest pytest-cov
- name: Test with pytest
run: py.test -o junit_family=xunit2 --junitxml result.xml -v --ff --cov=<my_package> --cov-report=xml --cov-report=term <my_tests>
- name: Coverage Report
if: always()
uses: aGallea/tests-coverage-report@1.3.1
with:
min-coverage-percentage: '100'
fail-under-coverage-percentage: 'true'
cobertura-path: ./coverage.xml
junit-path: ./result.xml

assicurati di sostituire il E sopra con il nome del pacchetto e la cartella tests di conseguenza.

Questo è tutto! se apri una nuova pull request per aggiungere questo file, l’azione dovrebbe essere attivata automaticamente e vedrai il report:

Tieni presente che poiché non sono presenti modifiche nei file del pacchetto (file sorgente), non ci sono dettagli sulla copertura da presentare. L’immagine sopra è stata presa da la mia richiesta di pull mentre aggiungo l’azione di copertura del test in uno dei miei repository pubblici.

Hai appena completato la prima azione (doppio significato) che cambierà la tua vita e ti renderà uno sviluppatore migliore. La nostra generazione è dipendente da Mi piace, applausi, voti positivi e geek come noi che vogliono mostrare la nostra professionalità anche con un rapporto di copertura del 100%. Ci piacerebbe ricevere feedback, suggerimenti e richieste di funzionalità per questa azione che possano migliorare la tua esperienza di test e la tua motivazione.