Come faccio a creare un ambiente in cui i test di riparazione sono considerati una priorità?

Sono un ingegnere informatico presso un'azienda di medie dimensioni. Abbiamo una piattaforma di test abbastanza solida in esecuzione su TeamCity. Esegue test unitari su ogni check-in e un test unitario giornaliero / esecuzione BVT.

Il problema è che abbiamo molti test unitari rotti.

Abbastanza spesso, sollevo l'inutilità dei test unitari se sono costantemente rotti e non mantenuti. Non essere in grado di vedere se una modifica ha causato una regressione rimuove la maggior parte del valore di una piattaforma di unit test.

Vorrei piantare un seme che creerà una cultura di buone abitudini: fissare i test quando sono rotti, vederli come preziosi, dare la priorità al fissaggio dei test insieme ad altri lavori.

Ho provato la corruzione (prodotti da forno!), Chiedendo semplicemente e parlando con i dirigenti della squadra. Tutti dicono che è una buona idea, ma vedo di essere l'unico a fare qualcosa al riguardo.

Qual è il modo migliore per iniziare a incoraggiare gli altri a risolvere i loro test e dare la priorità al fissaggio dei test nei loro sprint?

Se c'è un modo meno soggettivo per chiedere questo, sarei felice di accettare qualsiasi suggerimento.

— Codeman
fonte

pistola Nerf automatica finalizzato alla ragazzo rompere la costruzione ...

— cricchetto maniaco del

In realtà abbiamo una pistola automatica per nerf ... ma la build non è rotta, solo i test dell'unità :)

— Codeman

Rompere i test unitari dovrebbe comportare la rottura della build. ;)

— Jeroen Vannevel,

@ Ӎσᶎ: il buy-in è importante, ma non è possibile ottenere il buy-in per la risoluzione di un problema fino a quando le persone non sono effettivamente a conoscenza del problema. In questo caso il buy-in deve inizialmente provenire solo da team leader e manager. Il buy-in degli sviluppatori può avvenire in un secondo momento e generalmente lo sarà, naturalmente, quando il sistema di build è stato impostato per far pagare ai singoli sviluppatori i propri errori.

— Aaronaught il

Se le ciambelle falliscono, sei un brindisi. :-)

— Ross Patterson il

Risposte:

Fallo in modo che sia impossibile rilasciare effettivamente qualcosa senza correggere i test.

Fallire la compilazione se qualche test fallisce.
Fallire la compilazione se qualche test viene ignorato.
Fallire la compilazione se la copertura del test scende al di sotto di un certo livello (quindi le persone non possono semplicemente eliminare i test per aggirarlo).
Utilizzare il server CI di fare la vostra build di rilascio, e solo consentire costruisce da goccia di build del server per essere promosso a SVS / staging / produzione / qualunque cosa.

Il fatto è che se la tua build viene interrotta per più di circa 15 minuti alla volta (e questo include test falliti), allora non stai facendo un'integrazione continua .

L '"opzione nucleare" è che il tuo server di controllo del codice sorgente rifiuti commit / check-in da qualsiasi utente diverso da quello che ha rotto la build. Ovviamente un amministratore deve essere in grado di sovrascriverlo temporaneamente se detta persona va in vacanza - ma, se tutti sanno che tutto il team è fregato fino a quando non risolvono i loro test, lo risolveranno rapidamente.

Una buona politica (che è ancora meglio quando è automatizzata) è di riportare l'origine all'ultimo commit stabile noto dopo 15 minuti di fallimento della compilazione. In altre parole, se non riesci a risolverlo o non sai cosa ha causato l'interruzione della compilazione o del test, ripristinalo e lavora localmente fino a quando non viene risolto: mai fare in modo che altri sviluppatori agitino il pollice mentre ti macini problema a cui non importa.

PS Se hai già molti test falliti, puoi usare una "soglia finale" in CI. Impostalo in modo che la compilazione fallisca solo se ci sono più errori di test rispetto all'ultima volta. Questo, insieme a una regola di copertura, costringerà gli sviluppatori a migliorare eventualmente la situazione del test se vogliono essere in grado di continuare a lavorare.

PPS Mi rendo conto che questo potrebbe sembrare draconiano per alcuni, ma dipende tutto dalla tua cultura. Se arrivi a un punto in cui le persone non lasciano la build interrotta o i test falliscono (il mio team non lo fa quasi mai, anche se ogni tanto devo ricordare loro), allora non è necessario continuare con il set di regole più rigoroso. Anche se IMO dovresti sempre fallire la compilazione su un test unitario rotto. Talvolta i test di integrazione / browser possono fallire.

— Aaronaught
fonte

Mentre tutti i tuoi suggerimenti tecnici sono utili, penso che la parte più preziosa della tua risposta sia che "è tutta la tua cultura" perché più che un problema di disciplina, è un problema di utilità percepita del test. Preferirei metterlo in primo piano rispetto a un PPS

— user40989

@ user40989: ti sento. La cultura è qualcosa che devi coltivare, però. Se vuoi che le persone capiscano quanto sono importanti i test, a volte devi farlo in modo che le persone non possano ignorarli. Una volta che le persone si abitueranno a un alto livello di copertura del codice e test ecologici, non vorranno più tornare indietro, e quindi i tuoi sviluppatori lo imporranno per le nuove reclute. Beh, speriamo. Un team di analisti ritentivi guida e / o crea master e / o manager aiuta. :)

— Aaronaught,

FWIW: Il nostro intero processo di rilascio è ora automatizzato e la gente non penserebbe di avere test interrotti. Il responsabile del team si unisce a master, quindi avvia una build di rilascio e invia una richiesta di promozione agli amministratori di sistema che spingono letteralmente un pulsante per distribuire dagli artefatti di build ed eseguire test automatici di API e browser. Nessuno si lamenta mai di questo processo, perché consente di risparmiare tempo : passavamo 2 settimane a discutere su una versione, ora è sostanzialmente un'onda. Questo è ciò che intendo coltivando la cultura: tutti sanno che i 2 minuti in più per risolvere un test salveranno 2 ore dopo.

— Aaronaught,

I test delle unità che falliscono non sono il problema. Sono un sintomo .

Il vero problema è nella cultura. Devi camminare delicatamente: ecco i draghi . Non puoi cambiare la cultura da solo, ed essere la ruota cigolante alla fine ti renderà un emarginato. Letteralmente.

Suggerisco che se provi a trovare una persona anziana per difendere la causa e aprire la strada. Se fallisce, prova a sollevarlo in una riunione generale degli sviluppatori, senza puntare il dito o chiamare i nomi. Un'altra alternativa è quella di assumersi la responsabilità di fare un lavoro adeguato: basta correggere altri test ogni volta che si effettua un check-in. Tieni un diagramma sul muro che mostra quanti test falliscono nel tempo. Altri lo vedranno: forse accetteranno.

Non c'è una risposta facile.

— andy256
fonte

Essere la ruota cigolante mi ha portato al comando della squadra. Forse c'era qualcosa che non andava nel tuo cigolio? In tutta serietà, tuttavia, ciò parla di un problema di cultura molto diverso , non con il team di sviluppo ma con la gestione dell'azienda. Se la risposta della direzione a un incendio è quella di mettere gli occhiali da sole, allora vattene da lì. Ma se in realtà sei un negozio di sviluppo , al contrario di un dipartimento IT aziendale che produce software da un centro di costo, è abbastanza probabile che i manager si preoccupino di cose come la frequenza e la sicurezza con cui puoi rilasciare sul mercato.

— Aaronaught,