Differenza tra test unitari e sviluppo guidato dai test

64

Dalla lettura delle descrizioni, capisco che nei test TDD vengono eseguiti prima di scrivere la funzione e in Unit Testing, successivamente.

È questa la differenza principale o i due termini non possono nemmeno essere confrontati come tali. Forse, Unit Testing è parte integrante di TDD.

unit-testing tdd difference

— Shamim Hafiz
fonte

104

Unit Testing si riferisce a ciò che si sta testando, TDD a quando si sta testando.

I due sono ortogonali.

Unit Testing significa, bene, testare singole unità di comportamento. Una singola unità di comportamento è la più piccola unità di comportamento possibile che può essere testata individualmente in modo isolato. (So che queste due definizioni sono circolari, ma in pratica sembrano funzionare abbastanza bene.)

Puoi scrivere unit test prima di scrivere il tuo codice, dopo aver scritto il tuo codice o mentre scrivi il tuo codice.

TDD significa (di nuovo, in qualche modo ovvio) lasciare che i test guidino il tuo sviluppo (e il tuo design). Puoi farlo con unit test, test funzionali e test di collaudo. Di solito, usi tutti e tre.

La parte più importante del TDD è la D centrale . Hai lasciato che i test ti guidassero . I test ti dicono cosa fare, cosa fare dopo, quando hai finito. Ti dicono quale sarà l'API, quale sarà il design. (Questo è importante: TDD non riguarda prima la scrittura di test. Ci sono molti progetti che scrivono prima i test ma non praticano TDD. La scrittura dei test prima è semplicemente un prerequisito per poter consentire ai test di guidare lo sviluppo.)

— Jörg W Mittag
fonte

1

Bella risposta. aggiungerei ... TDD è quando permetti ai test di spingerti e funzionalità per attirare i tuoi sforzi di sviluppo ...

— Martin

Tuttavia non sono ortogonali. Non è possibile avere TDD senza unit test.

— Jacques B

1

@JacquesB, perché? I nostri test non sono quelli che chiameresti test di unità per qualsiasi definizione, dipendono troppo dall'infrastruttura e da altri componenti, ma abbiamo ancora abbastanza osservabilità che noi - almeno alcuni di noi - stiamo facendo TDD.

— AProgrammer

3

@AndrewWillems: TDD significa che i test guidano lo sviluppo . Non decidi come appare il design, ti dicono i test. Non decidi su cosa lavorare dopo, ti dicono i test. Non decidi quando hai finito, ti dicono i test. È perfettamente possibile scrivere prima i test, quindi ignorare tutto ciò che ti stanno dicendo. Ad esempio, è possibile scrivere prima i test, ma continuare a scrivere codice anche dopo che tutti i test sono verdi. Quindi, in altre parole: scrivi prima i test, ma li tratti come test e non permetti loro di guidare lo sviluppo.

— Jörg W Mittag,

1

@ JörgWMittag Potresti avere ragione in un modo purista di vederlo, ma sai anche che TDD non è in bianco e nero. Qualsiasi uso razionale del TDD non permetterebbe ai test di guidare completamente lo sviluppo, e sicuramente i test non decidono sempre che aspetto ha il progetto (forse i test unitari possono farlo parzialmente, ma non i test a un livello di astrazione più elevato). Che dire di refactoring? Questo è un aspetto molto importante del TDD. Anche nel mondo reale non esiste una cosa come "ignora tutto ciò che il test ti sta dicendo". Per definizione, se scrivi prima i test, usi "qualche forma di TDD".

— NickL

21

Unit Testing è un componente di Test Driven Development

È possibile eseguire test unitari senza eseguire test driven development. Tuttavia, non è possibile eseguire lo sviluppo guidato dai test senza utilizzare i test unitari.

Quando si eseguono test di unità tradizionali , si scrive test dopo aver scritto il codice.

L' approccio di sviluppo guidato dai test consiste nello scrivere unit test prima di scrivere il codice.

I vantaggi più interessanti del TDD (IMHO) rispetto al semplice test unitario:

Il codice è completamente testato in anticipo. È un test indolore.
Ti costringe a progettare correttamente le tue lezioni.
Ti costringe anche a renderlo semplice stupido .
Il ciclo di Red-Green-Refactor è l'assassino di procrastinazione assoluto!

Ti sei perso "unità" apposta nella dichiarazione: "Tuttavia non puoi fare lo sviluppo guidato dai test senza usare i test". ?

— ratkok,

@ratkok: no che non era apposta. Lascia che lo risolva.

Questa definizione mi piace di più. È meglio mettere insieme in parole rispetto ad altre risposte.

— Tek,

2

Probabilmente, puoi fare TDD usando test di modulo o test di sistema piuttosto che veri e propri test di unità. Non lo consiglierei, poiché perdi gran parte del vantaggio se i test richiedono troppo tempo per essere eseguiti, ma non è impossibile.

— Toby Speight,

13

TDD e Unit Testing sono due termini molto specifici che spesso vengono abusati.

TDD sta scrivendo un test che fallirà, quindi scriverà la quantità minima di codice necessaria per eseguirlo, quindi refactoring del codice per renderlo pulito. Questo viene fatto in cicli, fallisce -> passa -> refactor, aggiungendo un nuovo test per ogni requisito noto per il codice. Più recentemente, TDD è diventato ancora più specificamente sulla scrittura di unit test in quel ciclo, per distinguerlo da ATDD (un sottoinsieme di BDD) che sta scrivendo test di accettazione in un ciclo simile.

Il test unitario consiste nel testare un codice in unità piccole e isolate. La confusione comune qui è pensare che se si utilizza uno strumento di unit test, come xUnit o Rspec, per eseguire test che si stanno scrivendo unit test. Questo non è necessariamente vero. Tali strumenti possono essere utilizzati per eseguire test dire utilizzando il framework Selenium - in tal caso si stanno scrivendo test di accettazione utilizzando un runner di test unità. I test unitari sono test molto specifici che si concentrano su un piccolo pezzo di logica, isolato da tutto il resto per motivi di velocità (in modo da poterli eseguire spesso e ottenere un feedback rapido su nuovi bug).

— pdr
fonte

1

I test JUnit per JUnit stesso sono un buon esempio: una parte significativa di questi sono test funzionali e test di accettazione, non test unitari, anche se sono scritti in JUnit. Inoltre, il creatore di JUnit è anche il creatore di TDD, e JUnit è stato sviluppato utilizzando TDD utilizzando una quantità significativa di test funzionali e test di accettazione. Il test di accettazione è parte integrante del TDD.

— Jörg W Mittag,

6

TDD è l'approccio di scrivere i casi di test prima dello sviluppo come hai detto e quindi lo sviluppatore scrive il codice per passare i casi di test. Unit Testing è un termine usato per descrivere un tipo ristretto di test diversi da test di sistema, test di integrazione e test di collaudo.

— M.Sameer
fonte

3

TDD è un approccio filosofico alla scrittura del codice: scrivere prima i test. I test che scrivi sono test unitari.

— Tangurena
fonte

1

Il modo in cui separo i due è quello di considerare che TDD riguarda meno i test e più la progettazione del codice. I test unitari vengono quindi utilizzati per stabilire le aspettative per il codice finale. Quando il codice finale viene scritto e supera i test (specifiche), si dispone di codice progettato utilizzando i test.

— Grant Palin
fonte

1

Tutte le risposte eccellenti. Vorrei solo aggiungere che i test unitari tendono a considerare l '"unità" come un piccolo componente, mentre TDD si ingrandisce per includere test di integrazione e accettazione.

(Alcune varianti di TDD considerano l '"unità" come il più piccolo passo incrementale verso la funzionalità desiderata ...)

— Steven A. Lowe
fonte

dovrebbero, ma nella mia esperienza in realtà non lo fanno. Le aziende / i gruppi dichiarano di fare TDD, quando tutto ciò che fanno è forzare i programmatori a fare test prima con i test jUnit, quindi utilizzare il fatto che tutto è già stato testato durante lo sviluppo per eliminare (o ridurre notevolmente) il QA e i test di integrazione.

— jwenting

1

@jwenting non incolpa la metodologia per le carenze di coloro che affermano di praticarla. qualsiasi strumento può essere utilizzato in modo improprio

— Steven A. Lowe,

1

Non lo so, ma devi capire che c'è una grande differenza tra ciò che TDD è in teoria e ciò che è nella realtà. E poiché la maggior parte delle persone (incluso il PO) probabilmente vede sempre e solo la realtà, la differenza dovrebbe essere sottolineata da loro.

— jwenting

Considerando che TDD riguarda la progettazione: perché dovrebbe includere i test di accettazione? come "guiderebbe" il design?

— Vitalii Isaenko,

I test di accettazione di @VitaliiIsaenko forniscono l'ambito di massimo livello per i progetti

— Steven A. Lowe,