Test di unità e integrazione: come può diventare un riflesso

Tutti i programmatori del mio team hanno familiarità con i test unitari e i test di integrazione. Ci abbiamo lavorato tutti. Abbiamo tutti i test scritti con esso. Alcuni di noi hanno persino provato un miglior senso di fiducia nel proprio codice.

Tuttavia, per qualche motivo, scrivere unità / test di integrazione non è diventato un riflesso per nessuno dei membri del team. Nessuno di noi si sente veramente male quando non scrive unit test contemporaneamente al codice reale. Di conseguenza, la nostra base di codice è per lo più scoperta da test unitari e i progetti entrano in produzione non testati.

Il problema con questo, ovviamente, è che una volta che i tuoi progetti sono in produzione e funzionano già bene, è praticamente impossibile ottenere tempo e / o budget per aggiungere test di unità / integrazione.

I membri del mio team e io abbiamo già familiarità con il valore dei test unitari ( 1 , 2 ), ma non sembra aiutare a portare i test unitari nel nostro flusso di lavoro naturale. Nella mia esperienza, rendendo obbligatori i test unitari e / o una copertura target si traduce solo in test di scarsa qualità e rallenta i membri del team semplicemente perché non vi è alcuna motivazione auto-generata per produrre questi test. Inoltre, non appena la pressione diminuisce, i test unitari non vengono più scritti.

La mia domanda è la seguente: c'è qualche metodo che hai sperimentato che aiuta a creare un dinamismo / slancio all'interno del team, portando le persone che vogliono naturalmente creare e mantenere quei test?

Nessuno di noi si sente veramente male quando non scrive unit test contemporaneamente al codice reale.

Questo è il punto che devi affrontare. La cultura del tuo team deve cambiare in modo tale che non scrivere test durante lo sprint (o qualunque unità di tempo che usi) diventi un odore di codice quanto valori di hard-coding. Gran parte di ciò comporta una pressione tra pari. Nessuno vuole davvero essere visto come scadente.

Fai i test da solo. Visibilmente rimproverati quando non li fai. Fai notare dove un "buon" programmatore avrebbe scoperto quel bug se avesse scritto dei test unitari. Nessuno vuole essere cattivo. Fai in modo che questo comportamento indesiderabile sia negativo e le persone seguiranno.

Far sì che un'intera squadra desideri davvero la stessa cosa può essere piuttosto difficile. Accade spesso che vedere il valore di qualcosa non sia sufficiente in sé per incoraggiare le persone a cambiare il comportamento radicato. Anche coloro che apprezzano il cambiamento e che lo desiderano specificamente a volte possono anche essere responsabili della lotta inconscia.

Il problema riguarda davvero la motivazione individuale e non la motivazione del team in quanto tale. Arriva un momento in cui ti arriva un momento di chiarezza, o come risultato di qualcosa che ti è sembrato finalmente compreso, oppure a causa di un nuovo strumento o di qualche altra cosa soggettiva che fa sì che il programmatore medio inserisca tutto e cambi completamente il processo. Il tuo lavoro - se lo desideri, tranne che per quello - è vedere se c'è un modo per te o per il team di scoprire quali cose saranno i fattori scatenanti della chiarezza per ogni singolo membro del team.

Per me personalmente, è stato semplicemente scoprire il framework StoryQ per BDD in DotNet, il che ha reso troppo facile ignorarlo e mi ha fatto superare la "barriera" test-first vs test-contemporaneamente. Successivamente ho riaffermato le mie scelte quando ho trovato NCrunch per Visual Studio. Metà della battaglia a volte non è nel vendere l'idea, ma piuttosto nel ridurre semplicemente lo sforzo richiesto per introdurre un cambiamento radicale nelle abitudini ... e anche allora può richiedere un po 'di tempo e lavoro. Questi stessi trigger personali, tuttavia, non erano sufficienti per influenzare l'approccio dei miei colleghi in quel momento, che stanno ancora scrivendo la maggior parte del loro codice di test contemporaneamente o anche dopo il loro codice di implementazione.

A volte anche, c'è una riluttanza a cambiare il modo in cui le cose vengono fatte, a causa della paura intrinseca, della sfiducia o della visione sgradevole dello sforzo richiesto per imparare a fare qualcosa di diverso, anche quando il ragionamento per il cambiamento è valido. Se l'intera piattaforma di test viene utilizzata per funzionare in modo specifico, può essere difficile giustificare la modifica del modo in cui le cose vengono eseguite e il potenziale cambiamento degli strumenti , soprattutto quando i test vecchi e nuovi dovranno continuare a coesistere per tutta la vita del progetto - e non vorrai certo riscrivere tutti i test che hai mai creato. La cosa strana è che a volte le persone sentono che questo è l'unico modo per adottare una nuova metodologia di test e che di per sé rende più difficile per le persone accettare il cambiamento sensibile in meglio.

In realtà, l'unico modo in cui qualcosa diventa riflessivo è quello di costringerti a farlo ancora e ancora finché non ti accorgi più di doverti concentrare eccessivamente su come farlo. A volte, l'unico modo per farlo in una squadra è stabilire politiche che potrebbero vedere un po 'draconiane, e praticare la programmazione in coppia e le revisioni del codice, e qualsiasi altra cosa che possa aiutare i membri della squadra a sostenersi a vicenda e letteralmente forzare il cambiamento nel comportamento da verificarsi. Tuttavia, affinché una tale strategia abbia davvero successo, richiede comunque un impegno fermo e onesto da parte di ogni singolo membro del team per accettare le misure necessarie e per partecipare al processo ... e molta pazienza da parte di tutti i soggetti coinvolti .

Nessuno di noi si sente veramente male quando non scrive unit test contemporaneamente al codice reale

Non sei sicuro di cosa intendi con "allo stesso tempo", ma che ne dici di scriverli prima del vero codice?

È facilmente comprensibile dal punto di vista psicologico il motivo per cui qualsiasi essere umano non vorrebbe preoccuparsi di scrivere test unitari dopo il codice. A quel punto il codice funziona già, quindi perché mai dovremmo testarlo? Una sorta di pigrizia avviene automaticamente perché è noiosa, apparentemente inutile e non scrivere test non sembra essere pericoloso. Di conseguenza, non conosco molti team che hanno continuato con un approccio test dopo un lungo periodo di tempo.

Nella mia esperienza, il test-first (stile TDD), tuttavia, è qualcosa a cui puoi diventare rapidamente dipendente perché ci sono almeno 2 vantaggi immediati, tangibili e che rilasciano endorfine:

• Ti aiuta a progettare il tuo codice faccia a faccia con requisiti eseguibili concreti e a renderlo sempre migliore mentre rifatti, il che è molto più mirato e gratificante rispetto al semplice controllo di qualcosa che già funziona.

• Il ciclo TDD è punteggiato da frequenti momenti di "barra verde" in cui puoi goderti il ​​gusto del successo immediato. Mantiene costantemente la tua mente soddisfatta e pronta a scegliere la prossima funzione da implementare.

Quindi non tenterei di far stare male la tua squadra quando non hanno scritto i test. Invece, proverei a farli stare bene mentre lo fanno. TDD è un modo per farlo.

per prima cosa devi assicurarti che scrivere un test ed eseguirlo sia facile, configurare il framework nei progetti attuali e rendere semplice la procedura di impostazione da includere nei progetti futuri

in questo modo quando un programmatore vuole disinserire una nuova funzionalità che sta provando a eseguire il debug, non deve saltare attraverso una dozzina di cerchi per far funzionare correttamente i test

più è difficile fare qualcosa, meno è probabile che ne abituerai

Una cosa che ho fatto che ha avuto un certo successo nell'istigare un cambiamento di cultura è quella di organizzare un seminario settimanale sul seminario di "unit test curation". Lo scopo ufficiale di questo è quello di aiutare a mantenere la suite di unit test veloce e aggiornata, ma lo scopo più importante, secondo me, è quello di fornire alle persone un modo a bassa pressione di entrare, porre domande e fare prove . Il fatto che tu sia disposto a dedicare un'ora o qualunque cosa alla settimana esclusivamente ai test invia anche il messaggio che questo è importante.

Penso che ottieni un po 'di cambiamento culturale in questo modo e inizi a rimuovere la barriera per farlo "riflessivamente", come dici tu. Le persone tenderanno a tornare alle vecchie abitudini al primo segno di avversità: avere un incontro come questo non risolverà il problema in un colpo solo, ma penso che avvierà un cambiamento culturale e rimuoverà la barriera che deriva da non proprio sapendo cosa stai facendo.

Avere un gruppo di programmatori in cui tutti vogliono naturalmente fare qualcosa è un'utopia (specialmente quando si parla di un grande gruppo).

I test di unità e integrazione sono una questione di standard . Si crea uno standard per un flusso di lavoro e ogni membro del team dovrebbe rispettarlo. Gli standard dovrebbero essere stabiliti con l'aiuto di professionisti del controllo qualità, perché lo sanno meglio. Un programmatore dovrebbe rispettare gli standard. Quello che puoi fare è rendere gli standard puliti, facili da capire e da seguire.

Non si tratta della fiducia nel proprio codice e dei desideri da utilizzare, si tratta della necessità di disporre di standard di codifica e test che tutti usano per fare cose buone e che ogni programmatore dovrebbe capirlo.

Quando fai in modo che le persone fin dall'inizio seguano lo standard, diventa un riflesso e verrà seguito. Stabilire una regola secondo cui nessun codice può essere inserito nella base di codici senza un unit test convincerebbe le persone che devono farlo. Per i repository di progetto ci sono regole ancora più restrittive. Ad esempio, le aziende effettuano test di unità prima di codificare effettivamente l'unità (quando effettuano le specifiche del modulo) e questo è un metodo molto valido. Se un programmatore inserisce il codice nel project / codebase, il codice viene eseguito attraverso il modulo di test e se i test unitari non passano, tornano al lavoro.

Se al momento è difficile aggiungere standard e regole, almeno pensa ad aggiungerli in progetti futuri.