Recentemente mi sono imbattuto in questo problema quando un cliente era a bordo con la nostra metodologia, ma il management più alto ha capito che gli sviluppatori stavano spendendo il loro tempo per testare piuttosto che svilupparsi e ne erano preoccupati - dopotutto il test! Ho bloggato su come ho affrontato qui:

link

Per riassumere, ho confrontato le nostre ore stimate rispetto alle ore effettive per il progetto e poi ho confrontato il nostro tasso di difetti con il tasso di difetti delle altre squadre. Nel nostro caso questi numeri sono stati confrontati favorevolmente e non c'erano più dubbi.

La mia conclusione basata su questa esperienza è:

...the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.

Su altri progetti, abbiamo lavorato con gli sviluppatori di clienti che non hanno creato test unitari o TDD e abbiamo dovuto mantenere i test che si sono interrotti. Tuttavia, diventa molto facile vendere l'approccio TDD a quegli sviluppatori di clienti quando puoi dire loro cosa hanno infranto il codice prima che lo sappiano!

Quindi nel tuo caso, lo farei di nascosto se necessario (forse c'è una piccola area del codice che puoi iniziare a testare i cambiamenti spesso o di cui sei responsabile), ma tieni traccia di i tuoi numeri - qual è lo sforzo per creare i tuoi test? Qual è il tasso di difetto? Come si confronta questo con altri progetti / membri del team?

Secondo me, nessuno dovrebbe chiedere il permesso o scusarsi per aver fatto il proprio lavoro in modo corretto e qualsiasi sviluppatore professionista dovrebbe tentare di testare il proprio codice con test automatici ovunque sia possibile e pratico. Speriamo che siano entrambe queste cose nel tuo caso. Buona fortuna!

Mostra il ritorno sull'investimento (ROI)

La scrittura di test automatici richiede tempo. Una volta. Eseguire test automatizzati richiede tempo zero, perché puoi fare qualcos'altro mentre sono in esecuzione.

Esempio: la funzionalità di test manuale X impiega 30 minuti. La scrittura di un test automatizzato richiederebbe 1 ora. Anche se non abbiamo bug, dovremo testare la funzione X dieci volte durante il corso del progetto man mano che i suoi livelli e componenti dipendenti vengono modificati. Quindi automatizzare il test della funzione X ci farà risparmiare 4 ore nel corso della vita del progetto.

In realtà, è quando si verifica un bug che i test automatizzati hanno davvero ripagato: in primo luogo, trovano gli errori precocemente e a basso costo, risparmiando tempo e imbarazzo. In secondo luogo, se hai un bug difficile e passi attraverso molti cicli di codice-build-test per capirlo, il tempo risparmiato sul test manuale si somma straordinariamente velocemente.

Le aziende comprendono il risparmio di tempo e denaro. Ecco come venderlo.

Se li hai già affrontati e non sono d'accordo, ma non ti senti a tuo agio a scrivere codice senza di loro ... quindi non chiedere più. Basta scriverli e non controllarli.

La gestione non conta le righe di codice, ma vedrà che tutti i tuoi assegni hanno tassi di passaggio più alti dal QA (o dai clienti) e alla fine chiederanno perché ... allora puoi essere tutto come " BAM! TDD! "

Non stai scherzando con il progetto, il processo o la fonte ... quindi non vedo un motivo negativo. Onestamente, non vedo un motivo per cui è diverso il tempo rispetto all'esecuzione di tutti i tuoi run + input + test dei risultati manuali.

1) Il cliente non ha pagato i test unitari

Il cliente (pensava che) ha pagato per una soluzione di lavoro. A seconda dei vincoli contrattuali che risolvono i difetti potrebbe essere effettivamente redditizio per la vostra azienda. Se c'è un blocco sufficiente. Quindi tornando a pagare per una soluzione di lavoro. TDD dovrebbe aiutare quell'obiettivo.

2) Il progetto non consente il tempo per TDD

TDD non richiede più tempo. Dovrebbe ridurre la quantità di codice estraneo o superfluo e focalizzare la base di codice su ciò che fa passare i test. Tutte le prove che passano, fatte salve la qualità e l'adeguatezza del test, indicano che il codice è stato eseguito.

3) Debito tecnico? Quale debito tecnico?

Ho l'impressione che tu stia discutendo per l'aggiunta retrospettiva di test al codice esistente. Questo è un incubo vendere nel migliore dei casi e non porta i benefici che potreste aspettarvi. Tuttavia, aggiungere test durante la correzione dei bug dovrebbe essere accettabile e aiutare a lungo termine.

Non consiglio di scrivere comunque i test come suggerito da Snorfus. In teoria sembra bello, ma i test unitari possono e fare cambiano nel tempo. Man mano che i requisiti cambiano, vengono aggiunte nuove funzionalità che devono essere aggiornate. Se lavori come parte di un team, i tuoi test di unità diventeranno obsoleti mentre altri aggiungono funzionalità / correzioni.

Sto affrontando i punti specifici che hai menzionato invece di crearne di nuovi perché c'è margine di manovra per progredire o capire perché viene bloccato.

Per ogni cliente che deve affrontare problemi di produzione,

1. Scrivi un test unitario e invia un'email al manager dicendo che tu ho aggiunto un test unitario per coprire lo scenario.

2. E digli che questo problema non si ripeterà più nella produzione perché il nostro test unitario funziona di notte e verremo a sapere prima che il codice vada in produzione guardando questo test dell'unità fallimento.

3. Digli che se avessimo già effettuato questo test unitario prima del il codice è andato in produzione, questo problema di produzione non avrebbe mai avuto successo.

Fai questo costantemente e con insistenza e presto sarà convinto. Ai manager non piace che il cliente si trovi di fronte a problemi di produzione e comprerà l'idea di testare l'unità. Buona fortuna.