Come gestire il codice commesso e unito che non ha test?

• Come gestiresti problemi come questo?

Dai un'occhiata a integrazione continua . Quando le persone si impegnano, dovrebbe esserci una build automatica che esegue i test unitari. Ciò consentirà di rilevare le regressioni introdotte nel nuovo commit. Non catturerà errori che non hanno test, il che richiederà un cambiamento di comportamento. Prendi in considerazione l'aggiunta di test unitari alla revisione del codice: se non esistono, non eseguono il commit.

Per un caso specifico, probabilmente ripristinerò l'unione (se possibile) e gli permetterò di farlo di nuovo una volta risolto il problema. Se il ripristino non è possibile, vorrei che chiunque abbia spinto il commit abbia abbandonato tutto fino a quando non ha risolto ciò che ha commesso. Ricorda che, a patto che la compilazione non funzioni, tutti sono bloccati.

• Indica una cattiva pianificazione piuttosto che un cattivo comportamento?

Non esattamente. Potrebbe essere una cattiva pianificazione in quanto c'è fretta di impegnarsi prima che qualcosa sia fatto (sembra che tu definisca fatto come testato), ma è più probabile che abbia una definizione di fatto che non corrisponde al tuo DoD (che è il comportamento).

• Chi è da "incolpare" se il codice che manca di test è rotto?

La persona che ha commesso il codice e chiunque ha approvato il commit non testato (revisori, leadership tecnica, ecc.)

• Come gestiresti problemi come questo?

Questo dipende dalla posizione in cui ti trovi. Se sei il loro capo, prendi provvedimenti per disciplinare. In caso contrario, prova a spiegargli che il lavoro codice ist il valore della società in cui ti trovi. Tutti devono essere consapevoli di questo fatto. Sono abbastanza sicuro che riconosceranno cosa c'è che non va.

D'altra parte, dovresti aggiungere i test da solo. Se non si è sicuri che verrà testato ora , potrebbe non essere mai testato. Perché, secondo LeBlanc, in seguito non equivale mai.

• Indica una cattiva pianificazione piuttosto che un cattivo comportamento?

Non se i test sono stati inclusi nella pianificazione.

• Chi è da "incolpare" se il codice che manca di test è rotto?

Come affermato da thegrinner - la persona che ha commesso il codice.

Penso che potrei aver inavvertitamente risposto alla tua domanda in un'altra domanda. Per riassumere ciò che ho scritto lì, è sempre una cattiva pratica commettere codice spezzato (o codice che interrompe i test) se altri programmatori estraggono spesso da quel repository di codice. Penso che l'approccio corretto sia semplicemente aspettarsi che tali cose accadano e impostare il repository del codice in modo tale da non influenzare gli altri indipendentemente.

In altre parole, la pratica generale dovrebbe essere quella di ramificarsi sul fare cambiamenti significativi (o anche insignificanti nell'interesse di essere approfonditi) e di impegnarsi nel tronco principale solo quando hai stabilito che non causerà problemi.

Direi che, sì, questo è un segno di una cattiva pianificazione piuttosto che di un cattivo comportamento. Le uniche persone a "incolpare" se il codice che manca di test è rotto sono quelli che impostano il repository del codice e / o impostano il sistema per l'invio del codice. È perfettamente normale che i programmatori commettano errori. Tuttavia, non è accettabile costruire un sistema che si incrina quando vengono commessi tali errori.

How would you handle issues like this?

• Lavorare sulla formazione degli sviluppatori meno bravi per migliorare.
• Lavorare per educare la gestione sul tempo / denaro sprecato causato da cattivi commit e scarsa qualità.
• Lavora per spingere soluzioni tecniche come i check-in con gating o "solo i lead del team possono impegnarsi"

Does it point to bad planning rather then bad behaviour?

A volte. Se una funzionalità è così importante a causa della pressione del tempo o delle dipendenze, si tratta di un problema di pianificazione. Se lo sviluppatore è pigro, o ha stimato che impiega una settimana (con test) e quindi taglia i test per raggiungere l'obiettivo che non è un problema di pianificazione (PM).

Who is to "blame" if code that lacks tests is broken?

Tutti. Anche se una persona ti ha spinto troppo, potresti comunque prendere il tempo per scrivere i test o tornare indietro nel programma. Anche se una persona era semplicemente pigra, la cultura / il capo / i pari lasciava che ciò accadesse e / o non attenuasse la naturale pigrizia umana.

Saranno fatti degli errori, ma l'autocompiacimento è ciò che distruggerà davvero il tuo dipartimento. Accettare questo problema e dare la colpa agli altri non lo migliorerà.