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

None of us actually feel bad when not writing unit tests at the same time as the actual code.

Questo è il punto che devi affrontare. La cultura della tua squadra deve cambiare in modo tale che non scrivere test durante lo sprint (o qualsiasi altra unità di tempo che usi) diventi un odore tanto simile al codice quanto i valori hard-coding. Gran parte di questo comporta la pressione dei pari. Nessuno vuole davvero essere considerato al di sotto degli standard.

Fai i test da solo. Visibilmente rimproverati quando non li fai. Indica dove un programmatore "buono" avrebbe catturato quell'errore se avessero scritto dei test unitari. Nessuno vuole essere cattivo. Fai in modo che questo comportamento indesiderabile sia negativo e le persone seguiranno.

Ottenere un'intera squadra per davvero vuoi la stessa cosa può essere piuttosto difficile. È spesso il caso che vedere il valore in qualcosa non è abbastanza di per sé per incoraggiare le persone a cambiare il comportamento radicato. Anche chi apprezza il cambiamento e chi lo desidera specificamente può a volte anche essere responsabile di combatterlo inconsciamente.

Il problema è in realtà una delle motivazioni individuali e non la motivazione del team in quanto tale. Arriva un momento in cui un momento di chiarezza ti raggiunge, o come risultato di qualcosa che senti di aver finalmente capito, o a causa di qualche nuovo strumento o qualche altra cosa soggettiva che fa sì che il programmatore medio faccia tutto e cambi completamente il processo. Il tuo lavoro - dovresti scegliere tranne che - è 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 StoryQ framework per BDD in DotNet, che ha reso troppo facile ignorare, e mi ha completamente superato la" barriera "test-first vs test-simultaneamente. Più tardi 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 lo sforzo richiesto per introdurre cambiamenti radicali nelle abitudini ... e anche allora può richiedere un po 'di tempo e lavoro. Questi stessi trigger personali tuttavia non erano abbastanza per influenzare l'approccio dei miei colleghi in quel momento, che stanno ancora scrivendo tanto 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 sono fatte, a causa di una paura intrinseca, sfiducia o visione sgradevole dello sforzo richiesto per imparare a fare qualcosa di diverso, anche quando il ragionamento per il cambiamento è sano. Se la tua intera piattaforma di test è progettata per funzionare in modo specifico, può essere difficile giustificare il cambiamento nel modo in cui le cose sono fatte, e potenzialmente cambiare la tooling , specialmente quando i test vecchi e nuovi dovranno continuare coesistere per tutta la durata del progetto - e certamente non vorrai dover 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 questo di per sé rende più difficile per quelle persone accettare il cambiamento sensibile in meglio.

In realtà, l'unico modo in cui qualcosa diventa riflessivo è costringerti a farlo più e più volte finché non ti accorgi che devi concentrarti troppo su come farlo. A volte, l'unico modo per farlo in una squadra è impostare politiche che possano apparire un po 'draconiane, e fare pratica di paia di programmazione e revisione del codice, e qualsiasi altra cosa che possa aiutare i membri del team a vicenda e letteralmente forza il cambiamento nel comportamento che si verificherà. Tuttavia, affinché tale strategia abbia davvero successo, richiede comunque un impegno fermo e onesto da parte di ogni singolo membro del team di accettare tali misure, se necessario, e di partecipare al processo ... e tanta pazienza da parte di tutti i soggetti coinvolti .

None of us actually feel bad when not writing unit tests at the same time as the actual code

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

È facilmente comprensibile dal punto di vista psicologico perché 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 si verifica automaticamente perché è noiosa, apparentemente inutile e non scrivere test non sembra essere pericoloso. Di conseguenza, non conosco molti team che hanno seguito un approccio di prova per un lungo periodo di tempo.

Nella mia esperienza, il test-first (stile TDD), tuttavia, è qualcosa a cui puoi facilmente diventare dipendente perché ci sono almeno 2 benefici immediati, tangibili, che rilascino l'endorfina:

• Ti aiuta a progettare il tuo codice faccia a faccia con i requisiti eseguibili concreti e rendere il design migliore e migliore del tuo refactoring, che è molto più utile e gratificante di un semplice controllo di qualcosa che funziona già.

• Il ciclo TDD è punteggiato da frequenti momenti di "barra verde" in cui puoi goderti il gusto del successo immediato. Tiene costantemente la mente soddisfatta e pronta per la prossima funzionalità da implementare.

Quindi non proverei a far sì che la tua squadra si senta male quando non ha scritto i test. Invece, proverei a farli sentirsi bene come fanno. TDD è un modo per farlo.

per prima cosa dovrai assicurarti che scrivere un test e eseguirlo sia semplice, ottenere il framework impostato nei progetti attuali e rendere la procedura di impostazione semplice da includere nei progetti futuri

in questo modo quando un programmatore vuole annullare una nuova funzione che sta tentando di eseguire il debug, non deve passare attraverso una dozzina di cerchi per eseguire correttamente i test

più akward è qualcosa da fare, meno probabile è che ti prenda un'abitudine

Una cosa che ho fatto è stata un po 'di successo nell'introdurre un cambio di cultura è quello di organizzare un seminario settimanale di "verifica unitaria". Lo scopo ufficiale di questo è di aiutare a mantenere la suite di test unitaria veloce e aggiornata, ma lo scopo più importante, a mio avviso, è quello di offrire alle persone un modo semplice per entrare, porre domande e fare prove pratiche. . Il fatto che tu sia disposto a passare un'ora o qualsiasi altra settimana esclusivamente nei test invia anche il messaggio che questo è importante.

Penso che tu abbia un po 'di cambiamento culturale in questo modo e inizi a rimuovere la barriera per farlo in modo "riflessivo", come dici tu. Le persone tenderanno a tornare alle vecchie abitudini al primo segno di avversità - avere un incontro come questo non lo risolverà in un colpo solo, ma penso che avvierà un cambio di cultura e rimuoverà la barriera che deriva dal non realmente sapendo cosa stai facendo

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

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

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

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

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