Come creare un ambiente in cui i test di fissazione sono considerati prioritari?

Fai in modo che sia impossibile pubblicare qualsiasi cosa senza correggere i test.

1. Fallisce la compilazione se qualche test fallisce.
2. Fallisce la compilazione se alcuni test vengono ignorati.
3. Fallisce la build se la copertura del test scende al di sotto di un certo livello (quindi le persone non possono semplicemente eliminare i test per aggirare il problema).
4. Utilizza il server CI per eseguire i build di rilascio e solo consente di promuovere i build dalla generazione di build del server in UAT / staging / production / whatever.

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

L '"opzione nucleare" è far sì che il server di controllo sorgente rifiuti i commit / i checkin da qualsiasi utente diverso da quello che ha rotto la build. Ovviamente un amministratore deve essere in grado di ignorarlo temporaneamente se questa persona va in vacanza - ma, se tutti sanno che la intera squadra è fottuta fino a quando non correggono i test, allora la risolveranno maledettamente .

Una buona politica (che è ancora migliore quando è automatizzata) consiste nel ripristinare la sorgente sull'ultimo commit stabile noto dopo 15 minuti di mancato completamento della build. In altre parole, se non riesci a risolverlo, o non sai cosa ha causato la rottura del test o della build, allora ripristinalo e lavora localmente fino a quando non viene risolto, mai fare in modo che altri sviluppatori si divertano. pollici mentre ti allontani da un problema a cui non importa.

P.S. Se già hanno fallito molti test, puoi usare una "soglia finale" in CI. Configuralo in modo che la compilazione fallisca solo se ci sono più fallimenti di test rispetto all'ultima volta. Questo, insieme a una regola di copertura, costringerà gli sviluppatori a migliorare la situazione di test se vogliono continuare a lavorare.

P.P.S. Mi rendo conto che questo potrebbe sembrare draconiano per alcuni, ma è tutto nella tua cultura. Se arrivi a un punto in cui la gente non lascia la build non funzionante oi test falliscono (il mio team non lo fa quasi mai, anche se occasionalmente devo ricordarli), non è necessario continuare con il più rigido insieme di regole. Sebbene IMO si dovrebbe sempre fallire la build su un test unitario rotto. I test di integrazione / browser possono fallire a volte.

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

Il vero problema è nella cultura. Devi calpestare delicatamente: qui si trovano i draghi . Non puoi cambiare la cultura da solo, e essere la ruota stridula, alla fine, ti farà diventare un emarginato. Letteralmente.

Ti suggerisco di provare a trovare una persona anziana che difenda la causa e faccia strada. Se fallisce, prova ad aumentarlo in una riunione generale degli sviluppatori, senza puntare le dita o chiamare i nomi. Un'altra alternativa è prendersi la responsabilità di fare un buon lavoro: basta aggiustare qualche altro test ogni volta che effettui il check-in. Tieni un grafico sul muro che mostra quanti test falliscono nel tempo. Gli altri lo vedranno: forse accetteranno.

Non c'è una risposta facile.