Unit test contro test di accettazione

Question

Sei per l'uno o l'altro? O tutti e due?

La mia comprensione è unit test:

• convalidare il sistema dal punto di vista dello sviluppatore
• Gli sviluppatori di aiuto pratica TDD
• codice mastio modulare
• assistere nel rilevare errori a bassi livelli di granularità

Prove di accettazione:

• convalidare 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

mi sento entrambi sono necessari. Tuttavia, per la minimizzazione del lavoro ridondante, è una buona idea per cercare di incorporare unit test in prove di collaudo? In altre parole, hanno la seconda chiamata l'ex. Non andare nella direzione opposta ha alcun senso?

Quali sono i tuoi pensieri in generale sul test di unità contro i test di accettazione, e come gestirli in relazione gli uni agli altri?

Answer 1

Test e protocolli di integrazione indicano se il codice è funzionante e completo; unit test ti dicono dove è mancato.

Se hai fatto un buon lavoro con test di accettazione e integrazione, e sono di passaggio, il codice sta attuando tutte le funzionalità che si suppone, e sta funzionando. Che bello sapere (è anche bello sapere che non lo è). Ma se non funziona, un test di collaudo non vi darà molto comprensione in che cosa ha sbagliato andato; poiché molte unità test di funzionalità, può essere una specie di vista dall'alto di fallimento. Questo è dove brillano unit test. Buone unit test ti dicono esattamente cosa è andato storto, con esattamente quale parte del codice. E 'più difficile sapere se hai scritto unit test sufficienti rispetto ai test di accettazione, ma quando si ha la prova di collaudo malfunzionante senza una prova di unità corrispondente in mancanza -. E' tempo di scrivere che unit test

Questo è tutto dal punto di vista di test. E, naturalmente, TDD non è (e non è ATDD) sui test. Per quanto riguarda la guida il vostro disegno, test di accettazione ti danno una vasta tabella di marcia ( "qui è dove si vuole andare") mentre unit test vi porterà al prossimo incrocio ( "girare a sinistra"). Sono entrambi preziosa a tale riguardo e, ancora una volta, il loro valore si completano a vicenda.

Non confondere loro; non li miscegenate. Prove di unità, in particolare, non dovrebbe dipendere da qualsiasi altra cosa, e sarebbe un errore per vincolare il test di unità, facendo test di accettazione a loro carico. Naturalmente si può condividere un po 'di codice del framework, ma dovrebbero essere indipendenti.

Answer 2

  

Tuttavia, per la minimizzazione del lavoro ridondante, è una buona idea per cercare di incorporare unit test in prove di collaudo?

No.

  

In altre parole, avere quest'ultimo [accettazione] chiamata ex [unità]. Non andare nella direzione opposta ha alcun senso?

Non preoccupatevi.

test

di accettazione sono spesso politici. Li mostrare alle persone che - in base al loro istinto -. Decidono di accettare o rifiutare

Poi si sostengono circa la validità delle prove di accettazione.

Quindi è discutere l'entità dei lavori e la prossima release.

Prove di accettazione non sono - in generale - tecnica. Se lo fossero, allora si avrebbe unit test formali e che sarebbe questo.

Non cercare di finezza politica. Abbraccialo. Lascia che accada.

---

Si può sperare che Acceptance Test-Driven Development (lead ATDD) a "test di accettazione sono scritti e concordati da tutta la squadra prima dell'inizio di sviluppo." Ma bisogna riflettere la realtà che qualsiasi cosa scritta in anticipo è specioso al meglio e nel peggiore dei casi trattabili.

La premessa dietro tutti i metodi agili è che si può solo accettare di arrivare a qualcosa di rilasciabile. Tutto dopo che è negoziabile.

La premessa dietro tutti i test-first (TDD, ATDD, o qualsiasi altra cosa) è che un test è un accordo ferrea. Tranne che non lo è. Con qualsiasi TDD (o ATDD) metodo può essere d'accordo - in linea di principio - alla prova Risultati , ma non hai realmente accettato di test si .

Si può derivare che il test non può facilmente essere scritto. O peggio, non può essere scritto a tutti. Si può accettare i risultati che sembrano testabile, ma risultano essere scarsamente definiti. E adesso? Queste sono cose che non si può sapere fino a quando si inizia lo sviluppo e arrivare a dettagli.

Tutti i test è importante. E nessun particolare tipo di test può essere un superset o un sottoinsieme di qualsiasi altro test tipo. Sono sempre parzialmente sovrapposte set. Cercando di coniugare in qualche modo risparmiare un po 'di lavoro rischia di rivelarsi una perdita di tempo.

Più test è meglio di qualsiasi altra cosa. L'unione di tutti i test ha più valore che cercare di forzare un rapporto sottoinsieme-superset tra i test.

Answer 3

Unità Test - la mia funzione specifica fa quello che dovrebbe fare, niente di più e niente di meno

.

Acceptance Test -. La mia domanda fa quello che dovrebbe fare

Esempio: Applicazione alle radici Calcolare di funzioni quadratiche. Prende ingressi di a, b, c, ritorna radici x1 e x2. Questa applicazione è costruita da funzioni scrivo aggiungere due numeri, sottrarre due numeri, moltiplicare due numeri, dividere due numeri, e la radice quadrata di due numeri.

Prove di unità -. Controllare che il mio dividono e si moltiplicano le funzioni funzionano correttamente, la mia radice quadrata funziona correttamente, il mio add e il lavoro Sottrai correttamente

Prove di accettazione. - Controllare che i miei calcola applicazione radici di funzioni quadratiche

Dal momento che tutta la mia applicazione è alle radici calcolare, non avrei una prova di unità che calcola anche le radici perché non v'è alcuna funzione individuale che lo fa.

Answer 4

In sintesi tutto quanto sopra,

• Prove di accettazione assicurarsi che si sta costruendo il cosa giusta
• I test unitari assicurarsi che si sta costruendo il cosa giusta

Answer 5

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

  

Tuttavia, per la minimizzazione delle ridondante   il lavoro, è una buona idea per cercare di   test di unità incorporano in accettazione   test?

avevo di nessuno su questo e aggiunge che v'è il pericolo di qui i test di unità di essere truccate in una certa misura che possono avere alcuni bug passano attraverso la seconda S. Lott. Ad esempio, in un menu a discesa che qualcuno può testare alcuni stati, ma probabilmente non tutti, in cui un tester può utilizzare dati diversi per scoprire un potenziale bug.

  

In altre parole, hanno la seconda chiamata   l'ex. Fa andare nella direzione opposta   direzione alcun senso?

Starei attento di loro mai giunto insieme. I test di unità rappresentano le prove dei più piccoli pezzetti di funzionalità, spesso così piccolo che un utente finale non avrebbe capito che ci possono essere centinaia di test solo per ottenere un modulo web per inserire i dati in un sistema CRM. test di collaudo di più su ciò che l'utente dei bisogni di applicazioni che possono essere più soggettiva, per esempio. "Questo aspetto abbastanza?" versus "Fa questo look giusto?" Non ci può essere tale marchio di "abbastanza buono", con prove di collaudo che non sono sicuro che avrei lavorato con test di unità. Generalmente se un test di unità non riesce, allora qualcuno deve decidere se correggere il codice o rimuovere la prova, come ognuno può essere una buona opzione a seconda delle circostanze.

  

Quali sono i tuoi pensieri in generale su   test unitari vs test di accettazione, e   come gestirli in relazione a ciascun   altro?

I test unitari sono sulla verifica dei pezzi più semplici di codice. Non ci può essere test di integrazione, ma questo è un livello più alto, come una volta che tutti i piccoli pezzi vengono controllati, fare la combinazione dei pezzi lavorare insieme, per es. c'erano cartoni del sabato mattina ho guardato crescendo che i giocattoli avuto uno potrebbe mettere insieme come "Voltron" o vari Transformers come i Constructicon che formavano Devastator. Prove di accettazione sono generalmente dal punto di vista dell'utente finale di, "Posso fare X con l'applicazione adesso?" avendo una risposta di "Sì", prima che qualcosa vada fuori dalla porta. Mentre alcuni casi di errore possono essere controllati in un test di collaudo, non è comune a fare un test approfondito di ogni possibile combinazione che si poteva entrare in un'applicazione. Tuttavia, test di unità possono riguardare le condizioni al contorno e pochi altri casuale come casi.