Domanda

Come ho capito da alcune sessioni di domande e risposte (vedi this e this ), i test unitari dovrebbero essere scritti dagli sviluppatori.

Nel mio precedente posto di lavoro abbiamo cercato di affidare questo compito a un ingegnere addetto al controllo qualità, ma non ha funzionato. Forse perché era già al centro di un progetto e non aveva la possibilità di fare una copertura significativa del codice o potrebbe essere per un altro motivo.

Pensi che sia una cattiva idea liberare uno sviluppatore dalla scrittura di unit test in questo modo?

È stato utile?

Soluzione

In generale, penso che sia una cattiva idea. I test unitari guidano lo sviluppatore a scrivere codice modulare (e quindi utile, riutilizzabile) perché il suo codice deve funzionare sia con il sistema di produzione sia con il codice di test.

Altri suggerimenti

Esiste una differenza sottile ma importante tra l'intento dei test unitari e dei test QA: I test QA convalidano la funzionalità; il test unitario convalida il design . Cioè, la vista esterna contrasta con la vista interna del prodotto.

Le persone con QA non hanno familiarità con il design interno del prodotto, che è intenzionale perché deve imitare la prospettiva dell'utente. Gli sviluppatori, d'altra parte, conoscono intimamente i meccanismi interni ed è per loro un meccanismo per convalidare il design sarebbe significativo, se non del tutto.

Quindi, è assolutamente naturale che gli sviluppatori non i responsabili del QA scrivano unit test.

Questo dipende da come prevedi di implementare il tuo flusso di lavoro di test.

Bad:

Lo sviluppatore scrive il suo codice e l'altra persona tenta quindi di aggiungere unit test per testare questo codice. Il problema qui è che lo sviluppatore non si preoccuperà di scrivere codice facilmente testabile. Si può impiegare molto tempo a cercare di adattare i test unitari al codice male testabile, oppure si perde tempo refattorizzando il codice originale in seguito per renderlo meglio testabile.

Buono:

Un'altra persona oltre allo sviluppatore scrive i test unitari e successivamente lo sviluppatore scrive il suo codice, cercando di ottenere tutti quei test in verde. All'inizio questo può essere un po 'imbarazzante perché per implementare i test devono esistere alcune interfacce di base, ma le interfacce di base devono essere definite nel documento di progettazione, in modo che lo sviluppatore possa preparare le interfacce per lo sviluppatore del test. Il vantaggio è che lo sviluppatore del test cerca di scrivere tutti i test che può pensare indipendentemente dalla reale implementazione, mentre lo sviluppatore originale avrebbe scritto dei test a seconda degli interni del suo codice, senza immaginare altri problemi. Altrimenti, si sarebbe già scagliato contro di loro nella sua attuazione.

Il "buono" L'approccio ha funzionato bene su due dei miei progetti, ma abbiamo usato un linguaggio non tipizzato (Smalltalk) in cui dovevamo solo concordare i nomi delle classi per far funzionare i test. In Java devi implementare almeno un'interfaccia per chiamare le funzioni.

Sì.

Uno sviluppatore scrive il più semplice per assicurarsi che l'unità "quot" fa quello che suppone di fare. Una persona di controllo qualità verifica l'intera applicazione.

Inoltre, un test unitario è codice e gli sviluppatori scrivono codice. Il più delle volte gli ingegneri addetti al controllo qualità non scrivono codice.

Lo sviluppatore deve scrivere i test unitari. Altrimenti è come se lo sviluppatore non dovesse preoccuparsi della qualità. Inoltre, i test unitari aiutano lo sviluppatore a scrivere codice migliore.

Forse hai sentito parlare di TDD ? " Test Driven Development " è davvero una buona pratica per lo sviluppo. Il suo scopo principale è quello di sviluppare test unitari prima di scrivere il codice reale (che è una cosa strana, quando iniziamo a usare TDD, lo ammetto) ...

Avere una persona dedicata al test unitario in una squadra può sembrare interessante a prima vista; come rivedrà tutto il codice. Ciò ridurrebbe anche il rischio che uno sviluppatore commetta lo stesso errore nel codice di produzione e nei test unitari.

Tuttavia, per essere testato in unità, il codice deve essere testabile; cosa può fare quando il codice che riceve non è testabile? Riscriverlo? Riflettilo? Senza test unitari?

In breve, penso che questa non sarebbe una buona idea .

Dove lavoro facciamo tutti i test unitari ma non sul tuo codice. Scrivi ancora codice testabile e ti concentrerai ancora sulla qualità. Gli sviluppatori acquisiscono maggiore familiarità con le aree del software su cui non stanno lavorando. Tutti conoscono la base di codice e possono subentrare ad altri sviluppatori.

Per un non sviluppatore del software di scrivere unit test sono d'accordo con tutte le altre risposte. È una cattiva idea.

Nella tua domanda hai detto che avevi una persona che faceva il test unitario. Un buon test unitario richiede molto sforzo a seconda della copertura del test richiesta. È ovunque dal 50% al 100% del livello di sforzo del team di sviluppo. Una persona che testerà molto codice degli sviluppatori sarà totalmente sopraffatta.

Non penso che sarebbe male, non penso che sarebbe possibile. Se il codice non è stato scritto prima, probabilmente non è testabile.

La persona addetta al QA sta facendo il refactoring del codice per renderlo testabile?

Se è così, allora va bene, e non mi interessa quale sia il loro titolo. In caso contrario, dubito che avranno successo.

Penso che sia generalmente negativo per il controllo qualità scrivere unità di test. I test unitari sono codice, sono strettamente correlati a come viene costruito il codice di sviluppo. Per questo motivo, lo sviluppatore conosce meglio quali test avrebbero più senso.

D'altra parte, credo che il QA dovrebbe rimanere il più vicino possibile ai test unitari. Il controllo qualità richiede una buona relazione con lo sviluppatore e cerca di comprendere la progettazione del codice. Perché? Quando uno sviluppatore sta scrivendo unit test, il focus è ancora sullo sviluppo, non sui test. Non puoi fidarti (non nel senso negativo) di uno sviluppatore di elaborare i migliori casi di test e di avere una buona copertura. Poiché il controllo qualità è specializzato nei test, potrebbe essere una buona idea mantenere il controllo qualità e lo sviluppo il più vicino possibile durante i test unitari.

Uno sviluppatore o un altro sviluppatore (revisore del codice) dovrebbero documentare i casi di unit test che in un certo senso dovrebbero basarsi sul codice sviluppato o sul progetto tecnico. Tuttavia, i test funzionali dovrebbero scrivere casi di test QA che dovrebbero basarsi sul Design funzionale.

La differenza fondamentale qui è che l'UT copre la logica, il flusso interno, le prestazioni, l'ottimizzazione mentre il QA copre il flusso funzionale per imitare l'esperienza dell'utente.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top