Come misurare che un team sta facendo lo sviluppo Test Driven

Proprio come un test unitario dovrebbe testare il comportamento e non implementare il tuo reparto dovrebbe misurare il risultato previsto della politica, non l'implementazione della politica.

Il tuo dipartimento vuole passare a TDD. Perché? Che cosa speri di ottenere attraverso TDD? Sono stati rilevati meno bug relativi alla regressione? Velocità più veloce sui casi? Quindi dovresti misurare queste cose invece di cercare un modo per misurare che tutti usano TDD.

Se i risultati sperati della tua spinta verso TDD non sono qualcosa di esternamente misurabile, ad esempio un'esperienza di sviluppo più divertente e un flusso migliore (una delle cose che mi piacciono di TDD), allora non dovresti aver bisogno di cambiare la tua testando tutto perché saresti "refactoring" del dipartimento.

Invece suggerisco di chiedere il feedback degli sviluppatori su come pensano che TDD stia andando. Se non fanno "buy-in" al concetto TDD, non importa come lo misuri: fallirà.

Il TDD non è qualcosa che una squadra si impegna a fare. È solo un mezzo per un fine. Gli obiettivi possono essere scrivere codice più gestibile, ridurre il numero di difetti, fornire più velocemente o migliorare la copertura del test, ma non "fare TDD".

TDD non è un proiettile d'argento. Misurare "se la squadra sta facendo TDD" non garantisce il successo come assicurarsi di bere la loro pozione magica ogni giorno. Inoltre, chiedendo al team di produrre degli indicatori che dimostrino che stanno praticando una tecnica che la squadra stessa ha chiesto in primo luogo è un po '... assurda. O comando-e-controllo fondamentalista.

I manager e i responsabili delle decisioni non dovrebbero chiedere il controllo su come il codice viene prodotto a livello micro (un tipico ciclo rosso / verde / refactoring è dell'ordine di pochi minuti). Da quando i contatori di fagioli si preoccupano di come sono stati raccolti i fagioli?

Dato che misurerai separatamente il test unitario (copertura del codice, copertura decisionale, ecc.), aggiungo un paio di ulteriori modifiche al processo.

1. Tutti i check-in devono passare attraverso la revisione del codice.
2. Le recensioni del codice dovrebbero essere monitorabili, vale a dire, non dovrebbero essere una recensione over-the-shoulder o come la programmazione di coppie. Dovresti essere in grado di recuperare i commenti di revisione del codice, le iterazioni e tali dettagli in un secondo momento. TFS ti consente di farlo.
3. Al momento della firma su una revisione del codice, i commenti di approvazione possono essere seguiti da una parte di testo predeterminata che indica a TDD. ad es .: "TDD FOLLOWED". In questo modo puoi sapere quali check-in hanno seguito TDD e, alla fine dell'anno, puoi inventare / calcolare più metriche come la percentuale di LOC con TDD.

TUTTAVIA , Non giudicherei il valore / l'efficacia di TDD basandosi esclusivamente su questi parametri. Penso che l'industria si sia evoluta abbastanza che la maggioranza capisca il valore di TDD.

Dal momento che desideri passare da uno sviluppo secondo test a design guidato dai test , puoi misurarlo meglio cercando la prova che i test sono stati scritti prima che il programma fosse cambiato.

Insegna al tuo team di impegnare i test falliti prima , in modo che possano essere misurati e quindi scrivere il codice per superare il test. Potrebbe essere necessario ispezionare manualmente la cronologia del repository o scrivere uno strumento personalizzato per farlo per te.

(Finirai per trattarlo come un check-off per ogni progetto, quindi se è necessario il check-in-first puoi sempre farlo diventare parte delle informazioni segnalate e fidarti dei programmatori / project manager. cioè "erano i test scritti prima del codice?")

Se una squadra vuole veramente fare TDD, è sufficiente eseguire un minimo di tracciamento per soddisfare la regola. Controlla prima i tuoi test e poi controlla il codice e dopo aver confrontato le date iniziali, hai qualche parvenza di prova.

Per avere un altro livello di approvazione, rendi questa parte della revisione del codice in cui qualcuno può verificare che si tratti di test significativi. Non è così difficile scrivere un test che fallisce senza nemmeno fare riferimento al codice che si suppone di testare. Non è proprio nello spirito di quello che stai cercando di fare.

Durante una parvenza di programmazione della coppia, tutti possono "firmare" il TDD.

Potresti non sentire il bisogno di portare le cose fino a questo punto, ma devi essere preparato a servire i poteri che sono.

Personalmente, penso che il TDD dovrebbe essere usato e valutato per risolvere qualche problema più grande. Se rilasciare meno bug sul tuo prossimo aggiornamento è una preoccupazione perché riduce la soddisfazione del cliente, puoi fare un sondaggio e chiedere ai clienti: su una scala da 1 a 10 (10 è il più doloroso) quanto più doloroso è stato il nostro ultimo aggiornamento (costruito su TDD) rispetto a quello precedente? È abbastanza buono per gli studi sui farmaci antidolorifici, dovrebbe essere abbastanza buono per il software.

È una richiesta stupida che prova l'idiozia di molti manager / contabili / cto ecc. che non capiscono che lo sviluppo del software è un processo un po 'unico in sé (quindi no, non importa che Toyota usi un processo specifico, tu non costruendo macchine)

Ad ogni modo, le sole cose che devono essere misurate sono i RISULTATI. Offrite software di qualità superiore? Lo consegnate più velocemente? L'attuale metodo di sviluppo (TDD o no) produce risultati almeno uguali o migliori con costi inferiori (tempo e denaro)?

Si riduce semplicemente al costo e ai risultati. Volete risultati migliori con costi uguali o inferiori o almeno lo stesso risultato con meno costi. È il rapporto tra il risultato finale e la linea di fondo che conta.

Il tuo team deve dimostrare che l'approccio TDD migliora la produttività (manutenibilità - > modifiche più facili - > risultati più rapidi - > meno tempo richiesto) e / o qualità del prodotto (meno bug - > meno tempo speso nel debugging - & gt ; prodotto affidabile | meno persone incazzato - > parti interessate più felici).

So che ci vuole più tempo per pensare e scrivere test, ma il software devel non si ferma quando è uscito il primo rilascio. E anche i beancounter devono comprendere (con forza) che lo sviluppo del software ha i suoi capricci, non è una scienza esatta e se possono fare un lavoro migliore, lascia che siano loro a farlo. Non costruisci case come costruisci automobili o aeroplani, un'attività di cupcake o servizi cargo. Perché dovresti creare software in questo modo?

Modifica: Potrebbero essere notizie per alcune persone ma molte cose semplicemente NON POSSONO essere misurate in modo affidabile. Puoi fingere di misurarlo e inventare metriche di cazzate, ma questo è tutto. Il marketing è uno dei domini strongmente colpiti da questa piaga.

Non sono sicuro che avresti bisogno di una misura diversa. Tu dici:

We had a goal for writing unit tests already....

... presumibilmente lo stai misurando in qualche modo. Il fatto che ora desideri scrivere test prima dovrebbe avere nessun effetto sulle tue metriche esistenti. Dopotutto, potrebbero esserci state delle volte in cui, ad esempio, per capire meglio il problema, qualcuno del team ha ha scritto un test prima del codice. Quindi in quel caso stavano già praticando TDD; semplicemente non lo chiamavano così, e alla direzione non importava.

L'obiettivo esistente è di avere test unitari; ancora avrai i test unitari dopo aver adottato TDD. È semplicemente un non-problema dal punto di vista di un bean-counter. Come altri hanno già detto, TDD di per sé non è un obiettivo.

TDD dovrebbe generare almeno 1 test unitario per classe. Per ogni classe in un progetto dovrebbe esserci almeno 1 test unitario che è stato scritto per quella classe, e verifica solo quella classe.

Test unitario a rapporti di classe, copertura del codice, ecc. ecc. sembrano cose che danno una misura significativa, ma non lo fanno.

Quello che vuoi misurare è la complessità delle classi, e quanto bene queste classi sono state testate. Maggiore è la complessità di una classe, maggiore è il rischio che la classe introduca in un sistema.

Puoi avere una copertura di prova del 100% su una classe estremamente complessa, ma ciò non significa che l'hai testata bene.

La complessità è la misura di quanti percorsi decisionali logici ci sono nel codice. Puoi avere una porzione di codice che genera 1 milione di possibili combinazioni decisionali e una copertura del 100% del codice. Ciò non significa che hai testato tutti i 1 milione di casi.

L'altro problema è quanto parte del sistema usa questa classe complessa?

Quindi questo significa che alcuni test unitari sono più importanti di altri, ed è proprio quei test che vuoi fare molto bene.

Questo è qualcosa che è molto difficile da misurare ...