Verifica del valore degli standard di prova

3

Attualmente stiamo sviluppando un concetto per i nostri standard di test. Fino ad ora, non abbiamo standard. Tutto ciò che facciamo è dire allo sviluppatore di scrivere test. Ora abbiamo la seguente idea di base:

Utilizzeremo la metrica di copertura descritta nell'articolo del blog Test degli sviluppatori Selezione delle metriche di test degli sviluppatori in visualizza lo status quo.

Non chiediamo quanto percentuale debba essere coperto il codice. Ciononostante vogliamo un qualche tipo di controllo. Pertanto controlleremo se la copertura si è significativamente ridotta nel tempo. Se questo è il caso, l'intera squadra verrà informata. Non dovrebbe esserci alcuna colpa personale.

Per incoraggiare lo sviluppatore a scrivere più test, gli chiederemo di fare la stima di una funzione con i test in mente, in modo che abbiano abbastanza tempo per scrivere i test.

Non abbiamo molta esperienza negli standard di prova. è un buon approccio? Questa metrica è utile? E cosa ne pensi della nostra strategia per controllare i membri del team?

Modifica

Alcune informazioni aggiuntive riguardanti il post di Sklivvz. Non abbiamo quasi alcun codice coperto. Complessivamente è di circa il 25%. Alcuni componenti non sono coperti. Il nostro problema è che i nostri sviluppatori, per lo più persone con più di 10 anni di esperienza, non scrivono affatto test. Pertanto investiamo molto tempo nel correggere i bug riscontrati dal nostro team di test. Quello che vogliamo è avere più garanzie che non rompiamo qualcosa implementando un'altra cosa e che non creiamo gli stessi bug.

Inoltre sarebbe bello lasciare che i test guidino i membri del nostro team a creare un'architettura migliore nei loro componenti. Personalmente l'ho visto in un componente in cui sono entrato più tardi e ho dovuto refactorizzare l'intero componente a un certo punto, perché non era nemmeno un po 'controllabile.

Sviluppiamo una piattaforma software che cresce da diversi anni. Perciò abbiamo molto codice che non è coperto dai test. Come ho detto sopra, vogliamo motivare i membri del nostro team a scrivere test per i loro componenti che stanno attualmente sviluppando.

    
posta Yggdrasil 27.05.2013 - 11:00
fonte

1 risposta

2

Caveat emptor: perché stai implementando gli standard di test?

L'unica risposta corretta qui è quella di valutare gli standard del test in confronto a quello che stai cercando di uscire dal test.

Esempio: se stai provando ad avere un'applicazione medica incorporata priva di difetti (come un pacemaker), allora i tuoi standard sono probabilmente troppo bassi. Se stai scrivendo prototipi di applicazioni da buttare via, come le demo, i tuoi standard sono decisamente troppo alti.

Un altro esempio: se il tuo team è molto anziano e hai bisogno di scrivere codice snello e veloce, probabilmente altre forme di test sono più importanti dei test unitari. Se hai una squadra junior che è incline a fare molti errori e vuoi implementare standard difensivi, allora questa strategia non sembra abbastanza strong.

Detto questo, direi che con gli standard che stai suggerendo, non otterrai molto dai test:

  1. La copertura del codice parziale è meglio di niente, ma se introduci complessità a causa dei test, potresti avere un conteggio dei difetti aumentato nelle parti non testate.

  2. La copertura del codice parziale non consente alla tua squadra di refactoring impunemente.

  3. Dare agli sviluppatori il tempo di scrivere i test è buono, ma chiedere loro di scrivere prima i test è molto meglio, e dare loro dei test di accettazione è probabilmente meglio nel tuo caso.

Come puoi vedere, le mie risposte sono molto generali, ma rappresentano la mia esperienza ripetuta. In nessun caso gli indici mix-and-match mi sono stati utili.

Ci sono due usi della copertura del codice, per quanto ne so:

  • quando il tuo codice ha una copertura ridotta (ad esempio < 85%), la copertura del codice è utile solo per identificare i luoghi che necessitano di testare l'amore. La percentuale è francamente irrilevante.

  • quando la copertura del tuo codice è alta, puoi utilizzare una metrica di copertura minima per trasformare la compilazione in rosso. Sì, l'alta copertura non garantisce la correttezza, ma una copertura bassa è certamente correlata con più difetti, quindi una volta che il tuo team ha raggiunto standard elevati è bene se può mantenerli.

La tua strategia di rendere il controllo della copertura discreta funzionerà solo se la squadra ha già una copertura di codice elevata, altrimenti dovranno sapere esattamente cosa coprire, nel qual caso dovranno disporre di una linea per linea costantemente disponibile mappa della copertura che hanno!

Infine, se hai un sacco di codice non testato semplicemente dando ai tuoi sviluppatori il tempo di scrivere test per nuove funzionalità non risolverà i problemi di copertura iniziale. Questo è importante, perché per rendere testabile il nuovo codice, il tuo team dovrà refactoring il vecchio codice , e per farlo con sicurezza ... devono prima testare il vecchio codice . Non hai specificato se questo è per un progetto greenfield o uno brownfield: fa una grande differenza.

Consentitemi di rispondere alle ulteriori informazioni fornite.

  • Vuoi abbreviare i tuoi cicli di feedback;
  • Vuoi motivare la tua squadra;
  • Vuoi che il tuo team scriva test;
  • Vuoi ridurre il conteggio degli errori per le nuove funzionalità;
  • Vuoi ridurre le regressioni;

Questi obiettivi sono lodevoli ma molto difficili da ottenere in una situazione ideale, per non parlare di uno scenario di applicazioni legacy complicato.

Quello che ti suggerisco è di concentrarti su quello più importante e di farlo prima e poi passare a quello successivo. Assicurati che, una volta avviato il rearchitecting dell'applicazione, le qualità architettoniche siano ben definite (ad esempio, le prestazioni sono una funzionalità).

Ad esempio:

  1. Metti insieme il tuo team di test e sviluppo e falli tornare con un buon piano per testare automaticamente l'applicazione. La soluzione deve essere raggiungibile entro alcuni limiti (tipicamente del tempo). Non vuoi una copertura del 100% in questa fase. Semplicemente vuoi che venga eseguito un setup di test automatico, con i test quick-win eseguiti su di esso.

  2. Una volta completato quanto sopra, imposta alcuni obiettivi concreti sulla qualità e lascia che il team proponga la migliore strategia per raggiungerli. Tipicamente, verranno proposti alcuni test verticali , come test di integrazione. Misura tutto, sii trasparente, monitora successi e fallimenti. Vuoi qui la copertura del codice, ma anche i grafici di conteggio degli errori, ecc.

  3. Una volta eseguito quanto sopra, e se TDD è appropriato, refactoring, rearchitecture e unit test eseguono il codice legacy (wrap e refactor) e sviluppano nuove funzionalità usando TDD.

  4. ...

risposta data 01.06.2013 - 04:01
fonte

Leggi altre domande sui tag