Test unitari e test di accettazione

Question

Sei per l'uno o per l'altro? O entrambi?

mia comprensione è unit test:

• validare il sistema dal punto di vista dello sviluppatore
• aiutano gli sviluppatori pratica TDD
codice
• mastio modulare
• assist nel rilevare errori a bassi livelli di granularità

Test di accettazione:

• validare il sistema da parte delle imprese e punti di QC/QA di vista
• tendono ad essere di alto livello come sono spesso scritti da persone che non hanno familiarità con il funzionamento interno del codice

I sentire entrambi sono necessari. Tuttavia, per ridurre al minimo il lavoro ridondante, è una buona idea provare a incorporare i test unitari nei test di accettazione? In altre parole, chiedi a quest'ultimo di chiamare il primo. Andare nella direzione opposta ha senso?

Quali sono i tuoi pensieri in generale sui test unitari rispetto ai test di accettazione e su come gestirli in relazione l'uno con l'altro?

Answer 1

Test di accettazione e integrazione indicano se il codice è funzionante e completo; i test unitari ti dicono dove sta fallendo.

Se hai fatto un buon lavoro con i test di accettazione e integrazione, e stanno passando, il tuo codice sta implementando tutte le funzionalità che dovrebbe e sta funzionando. È bello saperlo (è anche bello sapere che non lo è). Ma se non funziona, un test di accettazione non ti darà molte informazioni su ciò che è andato storto; poiché verifica molte unità di funzionalità, può essere una sorta di visione d'insieme del fallimento. È qui che brillano i test unitari. Buoni test unitari ti dicono esattamente cosa è andato storto, con esattamente quale parte del tuo codice. È più difficile sapere se hai scritto abbastanza test unitari rispetto ai test di accettazione, ma quando hai un test di accettazione fallito senza un corrispondente test dell'unità guasto, è il momento di scrivere quel test unitario.

Questo è tutto dal punto di vista del test. E, naturalmente, TDD non è (e ATDD non lo è) sui test. Per quanto riguarda la guida del tuo design, i test di accettazione ti offrono un'ampia roadmap ("ecco dove vuoi andare") mentre i test unitari ti portano all'intersezione successiva ("svolta a sinistra"). Sono entrambi preziosi in questo senso e, ancora una volta, il loro valore si completano a vicenda.

Non confonderli; non miscegenarli I test unitari, in particolare, non dovrebbero dipendere da nient'altro, e sarebbe un errore limitare i test unitari facendo dipendere da loro il test di accettazione. Ovviamente possono condividere qualche codice quadro, ma dovrebbero essere indipendenti.

Answer 2

Tuttavia, per ridurre al minimo il lavoro ridondante, è una buona idea provare a incorporare i test di unità nei test di accettazione?

No.

In altre parole, hanno quest'ultimo [accettazione] chiamare l'ex [unità]. Andare nella direzione opposta ha senso?

Non disturbare.

I test di accettazione sono spesso politici. Li mostri a persone che, in base al loro istinto, decidono di accettare o rifiutare.

Quindi si discute sulla validità dei test di accettazione.

Poi discutete sullo scopo del lavoro e sulla prossima versione.

I test di accettazione non sono - generalmente - tecnici. Se lo fossero, allora avresti test unitari formali e sarebbe quello.

Non cercare di migliorare la politica. Abbraccialo. Lascia che accada.

---

Si può sperare che Acceptance Test-Driven Development (ATDD) porta a "test di accettazione sono scritti e concordati da tutta la squadra prima dell'inizio di sviluppo." Ma devi riflettere la realtà che qualsiasi cosa scritta in anticipo è speciosa nella migliore delle ipotesi e negoziabile nel peggiore dei casi.

La premessa dietro tutti i metodi Agile è che puoi solo accettare di arrivare a qualcosa di sbloccabile. Tutto dopo è negoziabile.

La premessa dietro a tutti i test-first (TDD, ATDD o qualsiasi altra cosa) è che un test è un accordo rivestito di ferro. Tranne che non lo è. Con qualsiasi metodo TDD (o ATDD) è possibile concordare - in linea di principio - con il test risultati, ma non si è realmente d'accordo sul test stesso.

È possibile che il test non possa essere facilmente scritto. O peggio, non può essere scritto affatto. Puoi accettare i risultati che sembrano verificabili, ma risultano essere scarsamente definiti. E adesso? Queste sono cose che non puoi sapere fino a quando non inizi lo sviluppo e ottieni dettagli.

Tutte le prove sono importanti. E nessun particolare tipo di test può essere un superset o un sottoinsieme di qualsiasi altro tipo di test. Sono sempre set parzialmente sovrapposti. È probabile che cercare di combinare in qualche modo un po 'di lavoro sia una perdita di tempo.

Altri test sono meglio di qualsiasi altra cosa. L'unione di tutti i test ha più valore che provare a forzare una relazione subset-superset tra i test.

Answer 3

Questi sono solo la mia opinione personale sulla questione di alcuni tipi di test:

Tuttavia, per la minimizzazione dei ridondante lavoro, è una buona idea per cercare di unit test incorporare nella accettazione test ?

Avrei il secondo di S. Lott su questo e aggiungo che qui c'è il pericolo che i test unitari vengano truccati in una certa misura e che alcuni insetti possano passare. Ad esempio, su un menu a tendina qualcuno potrebbe testare alcuni stati ma probabilmente non tutti, in cui un tester può utilizzare dati diversi per scoprire un potenziale bug.

In altre parole, chiamare quest'ultimo come . Andare nella direzione opposta a ha senso?

Farei attenzione ad accoppiarli mai insieme. I test unitari rappresentano test dei più piccoli bit di funzionalità, spesso così piccoli che un utente finale non capirebbe che potrebbero esserci centinaia di test solo per ottenere un modulo web per inserire i dati in un sistema CRM. I test di accettazione sono più relativi a ciò che l'utente dell'applicazione desidera, che può essere più soggettivo, ad es. "Questo sembra carino?" contro "Questo sembra giusto?" Può esserci quel marchio di "abbastanza buono" con test di accettazione che non sono sicuro funzionerebbe con i test unitari. Generalmente, se un test unitario fallisce, allora qualcuno deve decidere di correggere il codice o rimuovere il test, in quanto ciascuno può essere una buona opzione a seconda delle circostanze.

Quali sono i tuoi pensieri, in generale, sui test di unità vs. test di accettazione, e come gestirli in relazione gli uni altro?

I test unitari riguardano la verifica delle parti di codice più semplici. Ci possono essere test di integrazione, ma questo è un livello più alto, una volta che tutti i piccoli pezzi sono stati controllati, fare in modo che la combinazione dei pezzi funzioni insieme, ad es. c'erano cartoni animati del sabato mattina che stavo osservando crescere con giocattoli che si potevano comporre come "Voltron" o vari Transformers come i Constructicons che formavano Devastator. I test di accettazione sono generalmente dal punto di vista dell'utente finale, "Posso fare X con l'applicazione ora?" avere una risposta di "Sì", prima che qualcosa vada fuori dalla porta.Mentre alcuni casi di errore possono essere verificati in un test di accettazione, non è comune fare un test approfondito di ogni combinazione possibile che si possa inserire in un'applicazione. Tuttavia, i test unitari possono coprire condizioni al contorno e pochi altri casi casuali.

Answer 4

Test di unità: la mia funzione specifica fa ciò che deve fare, nient'altro e nientemeno.

Test di accettazione: la mia applicazione fa ciò che deve fare.

Esempio: applicazione per calcolare le radici delle funzioni quadratiche. Accetta gli input di a, b e c, restituisce le radici x1 e x2. Questa applicazione è costruita dalle funzioni che scrivo per aggiungere due numeri, sottrarre due numeri, moltiplicare due numeri, dividere due numeri e prendere la radice quadrata di due numeri.

Test di unità: verificare che le funzioni di divisione e moltiplicazione funzioni correttamente, che la mia radice quadrata funzioni correttamente, che il mio add e sottrarre funzionino correttamente.

Test di accettazione: verificare che la mia applicazione calcoli le radici delle funzioni quadratiche.

Poiché la mia intera applicazione deve calcolare le radici, non dovrei avere un test unitario che calcoli anche le radici perché non esiste una funzione individuale che lo faccia.

Answer 5

In sintesi tutto quanto sopra,

• Prove di accettazione assicurarsi che si sta costruendo la cosa giusta
• Prove di unità assicurarsi che si sta costruendo il cosa giusta