Share
Questo è un estratto dall'eBook Testing Unit Affinity, di Marc Clifton, gentilmente fornito da Syncfusion.
Il solito motto che sentiamo riguardo a qualsiasi metodologia software è che migliora l'usabilità e la qualità, riduce i tempi di sviluppo e test e porta il prodotto sul mercato più velocemente e con meno bug. Questi sono obiettivi ambiziosi, ma devo ancora vedere una metodologia per fornire il Graal dello sviluppo del software.
In definitiva, la ragione principale per scrivere i test unitari è dimostrare la correttezza, e ciò accade solo se si scrivono i test unitari bene. I test unitari di per sé non miglioreranno direttamente l'usabilità o la qualità del prodotto. È ancora possibile fare confusione con l'applicazione, a prescindere che sia provata o meno, e non è certo garantito che riduca i tempi di sviluppo e di test (ne parleremo più avanti) o anticipi il lancio del prodotto al mercato.
Quindi, cerchiamo di essere chiari e reali fin dall'inizio: il test delle unità può essere utilizzato per verificare la correttezza e qualsiasi effetto collaterale ciò che accade in relazione al tuo processo di sviluppo deve essere bilanciato con lo sforzo di scrivere e mantenere utili test unitari.
Test unitari ben scritti ti daranno un misurabile grado di fiducia che la miriade di metodi che compongono la tua applicazione si comporteranno correttamente. Il modo più semplice per effettuare oggettivamente questa misura è un test di copertura: quale percentuale dei metodi nella tua applicazione ha scritto test unitari contro di essi? Sebbene questa domanda non riguardi direttamente se un metodo debba essere considerato un'unità (discusso più avanti), o se i test siano significativi, è comunque una misurazione che puoi prendere in qualsiasi momento e può essere usato come parametro per la correttezza di la tua applicazione.
Il test delle unità è un processo iterativo: ci saranno sempre bug che non sono stati testati con le unità. Tuttavia, il numero di bug segnalati nel tempo e il numero di problemi non risolti rispetto a quelli risolti fornisce informazioni significative sulla salute dell'applicazione. Mentre è impossibile dire, "Con il test delle unità, il numero di bug è stato ridotto del 50 percento", è possibile misurare quanti bug l'applicazione ha a causa della copertura incompleta del test unitario. Mentre scrivi i test unitari per verificare il problema e la correzione, puoi anche misurare quanti test unitari hai scritto rispetto ai bug segnalati rispetto al numero totale di test unitari.
Tutti questi benchmark apportano un certo grado di obiettività al tuo processo di sviluppo. Pertanto, uno dei vantaggi del testing unitario è che fornisce a tutti, dagli sviluppatori ai manager, informazioni oggettive che possono essere ricondotte nel processo di sviluppo per migliorare tale processo.
Un altro vantaggio è la ripetibilità, altrimenti noto come test di regressione. Man mano che un'applicazione matura, vogliamo assicurarci che esistano, lavoro il codice non è rotto Scrivendo unit test contro i metodi mentre vengono scritti e aggiungendo unit test per i bug come vengono riportati, tutti questi possono essere ritestati automaticamente quando viene aggiunto un nuovo codice o viene modificato il codice esistente. I test unitari diventano uno strumento di riduzione dei tempi significativo quando si tratta di testare se un'applicazione si comporta ancora correttamente dopo un cambio di codice minore o significativo. Mentre il test unitario non sostituisce i test di usabilità, test delle prestazioni, test di carico e così via, aiuta sicuramente ad eliminare il tempo sprecato nella domanda comune: "Funzionava prima; perché non lo fa ora? "
È facile verificare che un metodo stia facendo la cosa giusta quando tutti i processi nel metodo vengono eseguiti in modo lineare. Tuttavia, una volta aggiunto un Se dichiarazione o a interruttore dichiarazione, stai creando complessità ciclomatica, che è un modo elegante per dire che il tuo codice ora ha più percorsi di esecuzione. I test unitari più utili sono quelli che testano ogni singolo ramo di codice ciò si verifica nel tuo metodo. Scrivere questi tipi di test unitari può essere scrupoloso, ma vale la pena, poiché garantisce che almeno ogni ramo di codice è stato eseguito, il che non è qualcosa che può verificarsi durante il test di accettazione, test di usabilità o altri test che la garanzia della qualità reparto (se ne hai uno) si esibisce.
Nel corso di questa serie, daremo un'occhiata a una serie di strategie e suggerimenti diversi su come eseguire test unitari efficaci.
Accentsconagua