Secondo le regole del TDD, i test unitari sono scritti prima del codice di produzione, ma per quanto riguarda i test di integrazione che esercitano l'interazione tra oggetti cablati concreti (non simulati)?
Dovrebbero essere scritti prima dei test unitari o dopo il codice di produzione solo per testare il "cablaggio"?
Si noti che non sto parlando di test di accettazione o funzionali ma di test di integrazione di livello inferiore.
Risposte:
Il libro Rspec , tra le altre risorse BDD, suggerisce un ciclo come questo:
In sostanza, il processo è:
While behaviour required
Write an integration test for a specific behaviour
While integration test failing
Write a unit test to fulfil partial behavior
While unit test failing
Write code to make unit test pass
Commit
While refactoring can be done
Refactor
While unit test failing
Write code to make unit test pass
Commit
Push
Dichiarazione di non responsabilità: non ho dubbi sul fatto che questo porta al miglior codice e prodotto, ma può richiedere molto tempo. Ci sono tutti i tipi di difficoltà riguardo ai dati e al determinismo, quando si tratta di dire che i test di integrazione devono sempre passare. Non è appropriato in tutte le circostanze; a volte devi solo portare cose fuori dalla porta.
Detto questo, avere in mente un processo ideale è grandioso. Ti dà un punto da cui scendere a compromessi.
Il vero progetto mi ha mostrato che non è possibile scrivere unit test e quindi l'integrazione e anche la direzione opposta è sbagliata :-) Quindi, di solito scrivo unit test insieme a quelli di integrazione.
Perché? Fammi scrivere come vedo entrambi i tipi di test:
Test unitari - Oltre a Wikipedia e tutte le informazioni note, i test unitari ti aiutano a restringere il design , migliorare il modello, le relazioni. Il flusso è semplice: una volta che inizi a digitare un nuovo progetto / nuovo componente, la maggior parte delle volte stai realizzando una sorta di PoC . Quando hai finito, hai sempre metodi lunghi, classi lunghe, metodi e classi non coerenti, ecc.
I test unitari aiutano a rimuovere questi problemi come quando si eseguono test di unità reali utilizzando le classi mock (senza dipendenza da altri componenti) sopra descritte non sono verificabili. Il segno di base del codice non verificabile è una parte beffarda dei test perché sei costretto a deridere molte dipendenze (o situazioni)
Test di integrazione - test corretti e funzionanti ti dicono che il tuo nuovo componente (o componenti) lavora insieme o con altri componenti - questa è la definizione normale. Ho scoperto che i test di integrazione aiutano principalmente a definire il flusso su come utilizzare il componente dal lato consumatore .
Questo è davvero importante perché a volte ti dice che la tua API non ha senso dall'esterno.
Bene, cosa succede una volta che ho scritto unit test e test di integrazione in seguito?
Ho preso lezioni carine, design chiaro, buon costruttore, metodi brevi e coerenti, predisposto per l'IoC ecc. Una volta che ho dato la mia classe / API a un consumatore, ad esempio uno sviluppatore del team di integrazione o GUI, non è stato in grado di usare la mia API perché sembra non logico , strano. Era solo confuso. Quindi ho riparato l'API in base al suo punto di vista, ma ha anche richiesto di riscrivere molti test perché sono stato spinto a cambiare i metodi e talvolta anche il flusso su come utilizzare l'API.
Bene, cosa succede dopo aver scritto i test di integrazione e i test unitari in seguito?
Ho il flusso esatto, buona usabilità. Quello che ho anche sono grandi classi, codice non coerente, nessuna registrazione, metodi lunghi. Codice spaghetti
Qual è il mio consiglio?
Ho imparato il seguente flusso:
Si noti che ho fatto una piccola presentazione sui test di unità / integrazione, vedere la diapositiva n. 21 in cui è descritto lo scheletro.
I test unitari vengono utilizzati per testare il più piccolo bit testabile possibile di software in un'applicazione e per testarne la funzionalità. Ogni unità viene testata separatamente prima di riunirle in parti o componenti più grandi dell'applicazione.
È qui che arrivano i test di integrazione :
testano queste parti appena create che sono costituite dalle unità precedentemente testate durante il montaggio di queste parti. Il caso migliore sarebbe quello di scrivere i test a questo punto mentre si scrive l'applicazione stessa.
Tendo a considerare i test di integrazione molto simili ai test unitari. In quello sto trattando un sottoinsieme del codice come una scatola nera. Quindi i test di integrazione sono solo una scatola più grande.
Preferisco scriverli prima del codice di produzione. Questo ha il vantaggio di aiutarmi a ricordare quali pezzi non ho ancora collegato o che ho leggermente modificato un dettaglio nell'interazione degli oggetti.
A parte i test di accettazione, tendo a scrivere solo test di integrazione ai limiti di un'applicazione, per verificare che si integri bene con sistemi o componenti di terze parti.
L'idea è quella di creare oggetti adattatore che traducono da come la terza parte parla a ciò di cui la tua applicazione ha bisogno e testare questi traduttori rispetto al vero sistema esterno. Sia che tu faccia quel test per primo o per ultimo, penso sia meno importante che con i tuoi test unitari regolari perché
Le informazioni sul design fornite da TDD non contano molto qui poiché il design è praticamente noto in anticipo e in genere non c'è nulla di terribilmente complesso in questione, basta mappare le cose da un sistema all'altro.
A seconda del modulo / sistema che si desidera affrontare, può richiedere molta esplorazione, modifica della configurazione, preparazione dei dati di esempio, che richiede tempo e non si adatta molto bene in un breve circuito di feedback TDD.
Tuttavia, se ti senti davvero più a tuo agio a costruire il tuo adattatore in modo incrementale in piccoli passaggi sicuri, ti consiglio vivamente di iniziare il test, non può far male.
Puoi trovare esempi di questo approccio qui: http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html (sesto paragrafo) http://blog.8thlight.com/eric- smith / 2011/10/27 / thats-non-yours.html
Quindi avrei accettato la prima risposta ma è stata eliminata.
Per riassumere
In una data iterazione:
Tenere presente i test di integrazione mentre 1 e 2 per garantire la testabilità a livello di integrazione.
I test di integrazione non sono necessariamente scritti end-to-end nella fase 3, ma possono essere parzialmente scritti tra la fase 1 e 2.
I test unitari verificano blocchi discreti di codice all'interno del progetto.
I test di integrazione testano come il tuo codice si interfaccia con altri codici: in altre parole, testano l' interfaccia del tuo codice.
Scrivi unit test durante lo sviluppo di codice dietro un'interfaccia.
Scrivere test di integrazione quando si sviluppa l'interfaccia o qualsiasi codice che implementa l'interfaccia.
Ciò significa che a volte scriverai test di integrazione molto tardi in un progetto, perché la maggior parte del lavoro è dietro l'interfaccia: ad esempio un compilatore, un particolare servizio web che implementa diversi livelli di logica o ... qualcosa che coinvolge un sacco di logica interna.
Tuttavia, se stai implementando una serie di servizi REST o rifattorizzando il modello di dati e aggiungendo il supporto per le transazioni XA, inizierai a sviluppare test di integrazione quasi immediatamente, poiché la maggior parte del tuo lavoro è centrata sull'interfaccia, indipendentemente dal fatto che sia l'API REST o come il programma utilizza il modello di dati.