I "Test TDD" sono diversi dai Test unitari? [duplicare]

Mi piace video TDD di Roy Osherove in particolare la parte 'Cosa significa TDD?'.

Dipende tutto da cosa tu guidi 'da TDD (progettazione o sviluppo, o entrambi o ...) e cosa sia l'' unità ', che è sotto test, lo è davvero.

Il termine Unit Testing è diventato sovraccarico. I test del programmatore potrebbero essere più precisi e potrebbero aiutare a chiarire meglio il ruolo che questo tipo di test svolge nella pratica del TDD. Penso che stia davvero confrontando i test dei programmatori e quelli che coprono più di una classe / metodo / modulo.

Non penso che la pratica TDD escluda qualsiasi tipo di test per essere la "T". È una pratica e non è realmente un tipo di test (come qualcuno ha sottolineato nei commenti).

Tuttavia, il TDD ha l'effetto più ovvio al livello più basso (a livello di metodo / funzione), quindi i test dei programmatori vengono spesso utilizzati e assunti indirettamente quando si parla di TDD. Ma il TDD come pratica è ancora del tutto possibile quando si sale (pre-integrazione o test di integrazione). Diventa un po 'più difficile collegare rapidamente i test in errore con le linee del codice che devono essere aggiunte / modificate.

Test TDD Funzioni , non "unità"

a volte le caratteristiche corrispondono alle unità, a volte no. Di solito non lo fanno.

Test TDD scala - su o giù - come richiesto per testare una funzione. Se una funzione è "deve trasmettere aggiornamenti giornalieri in meno di 500 msec", il test TDD sembrerà un test unitario. Se una funzionalità è "deve costruire corretti binding prototipi di widget con sei strutture di diramazione opzionali", allora il test TDD sembrerà un test di accettazione. [caratteristiche parafrasate, ovviamente]

Caveat: non ha letto l'articolo; leggi Beck

Anche se non ho esperienza con TDD, aggiungerò la mia opinione su questo; -)

L'articolo afferma che l'approccio del TDD porta a test che potrebbero non aderire ai principi di un Test unitario, in particolare test in isolamento. Si potrebbe dire che i test unitari sono più di tipo bottom-up, mentre i TDD-Test, provenienti dalle user story, hanno un approccio top-down.

Penso che

1. Ha ragione a riguardo
2. Fa un pessimo lavoro di spiegarlo
3. Se vedi accadere, dovresti rifattorizzare i tuoi test. Non dare loro un nome diverso (ad es. TDD-Test) e sentirsi fantasiosi a causa di ciò, ma trasformali in veri e propri Test unitari.

FWIW, io uso il termine "TDD test" per riferirmi ai test che escono dal processo TDD, e "unit test" per riferirmi a quei test che verificherebbero che una "unità" soddisfa le sue specifiche. I due non sono esattamente gli stessi: un test TDD (il modo in cui io uso il termine) precede sempre un'aggiunta di codice all'unità sottoposta a test, ma tali test non sono necessariamente adeguati alla verifica di un modulo. Considera una funzione banale come isBetween - dato un intervallo e un numero, verifica che il numero rientri nell'intervallo. Implementando con TDD, potremmo trovare:

# first pass
def test_LowerMeansNotInBetween
    # zero is not between 2 and 4
    assert_false(isBetween(2, 4, 0))
end
def isBetween(low, high, testVal)
    false
end
# second pass
def test_BetweenMeansInBetween
    assert(isBetween(2, 4, 3))
end
def isBetween(low, high, testVal)
    low <= testVal
end
# third pass
def test_GreaterMeansNotInBetween
    assert_false(isBetween(2, 4, 5))
end
def isBetween(low, high, testVal)
    (low <= testVal) && (testVal <= high)
end

A questo punto, isBetween dovrebbe essere funzionalmente corretto (ma in realtà non ho provato a farlo funzionare, potrei sbagliarmi - questo è solo per motivi di illustrazione), ma i test non esercitano completamente il comportamento specificato . Per questo, potremmo aver bisogno almeno dei seguenti test:

def test_AtLowerBoundMeansBetween
    assert(isBetween(2, 4, 2))
end
def test_AtUpperBoundMeansBetween
    assert(isBetween(2, 4, 4))
end

che non ci ha causato l'aggiornamento di alcun codice. Per come la vedo io, tutti e cinque i test sono "unit test", ma solo i primi tre sono "test TDD".

come ha detto @Steven, i test TDD dovrebbero testare le funzionalità, o più in generale testano use cases . I test unitari hanno un ambito diverso e più piccolo: testare l'implementazione della classe dalla sua interfaccia come una singola unità di consegna; costituisce un test di accettazione per una singola classe

pensa a TDD come a produrre una serie di test di accettazione necessari per un certo sprint su un intero progetto, quindi lo scopo dello sprint è far passare i test di accettazione per tutto il progetto eseguito come una singola unità.

l'insieme di tutti i test sui casi d'uso, o test di accettazione è una garanzia che il software fa ciò che lo stakeholder ha chiesto al team di implementare

YES

Test di unità da solo è fondamentalmente un metodo per testare la parte logica più piccola di un programma.

TDD è un processo di sviluppo del software . In pratica ti dice come usare i metodi di test unitario in un modo più agile.

In altre parole, test unitario risponde alle domande " cosa fare? " e risposte TDD, " Come fare? "

Aggiornamento: Sento che cosa intendeva con il test TDD è il test delle funzionalità.

Non penso che ci sia davvero una sola risposta corretta a questo. TDD fornisce alcune indicazioni su quale tipo di test dovresti scrivere e su come dovrebbero essere correlate al resto del tuo sviluppo.

A seconda di chi usa il termine, tuttavia, "unit test" può coprire una gamma così ampia di possibilità che quasi inevitabilmente copre la maggior parte dei test TDD, ma allora, probabilmente, sarebbe difficile trovare qualsiasi verifica che almeno alcune persone non siano disposte a chiamare un test unitario ...

Conclusione: i test sostenuti da TDD coprono un intervallo abbastanza ampio, ma c'è almeno qualche accordo su ciò che sono. "Test unitario" è così poco definito da poter fare riferimento a quasi tutti i tipi di test. Come termine, significa quasi niente.

Una volta era una definizione IEEE per i test delle unità che mi piaceva perché era più generale e non si fondava sull'intero concetto TDD di testare le unità testabili più piccole possibili. Ora quella definizione è stata modificata per corrispondere alla versione EP che trovo sciocca. Per me, test delle unità significa controllare i punti di interazione tra gruppi più grandi di componenti in cui è più probabile che si verifichi una certa volatilità quando vengono apportate modifiche. Se vedi delle variazioni sulle definizioni là fuori, è perché la frase è stata cooptata dal pubblico di EP / TDD. Lo trovo uno dei fenomeni più irritanti nella cultura dei programmatori. Perché non possiamo semplicemente inventare nuove frasi piuttosto che reinventare quelle vecchie?