Quando dovrei scrivere test di integrazione?

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 alcun dubbio che questo porta al miglior codice e prodotto, ma può richiedere molto tempo. Ci sono ogni sorta di difficoltà riguardo ai dati e al determinismo, quando si tratta di dire che i test di integrazione dovrebbero sempre passare. Non è appropriato in tutte le circostanze; a volte devi solo tirare fuori le cose.

Detto questo, avere un processo ideale in mente è grandioso. Ti dà un punto da cui scendere a compromessi.

Il progetto reale mi ha mostrato che non è possibile scrivere test unitari e quindi l'integrazione e anche la direzione opposta è sbagliata :-) Quindi, di solito scrivo unit test insieme a quelli di integrazione.

Perché? Lascia che scriva come vedo entrambi i tipi di test:

1. Test unitari - Oltre a Wikipedia e a tutte le informazioni conosciute, i test unitari ti aiutano a restringere il tuo design , a migliorare il tuo modello, le relazioni. Il flusso è semplice: una volta che inizi a digitare nuovo progetto / nuovo componente, la maggior parte del tempo stai facendo una specie di PoC . Quando hai finito, hai sempre metodi lunghi, classi lunghe, metodi e classi non coerenti, ecc.

   I test unitari ti aiutano a rimuovere questi problemi come quando esegui test di unità reali usando le classi di mock (senza la dipendenza da altri componenti) sopra descritte non verificabili. Il segno base del codice non testabile è una grande parte di test di simulazione perché sei costretto a prendere in giro molte dipendenze (o situazioni)

2. Test di integrazione : test corretti e funzionanti ti dicono che il tuo nuovo componente (oi suoi componenti) funzionano insieme o con altri componenti - questa è la definizione normale. Ho trovato che i test di integrazione ti aiutano principalmente a definire flusso come utilizzare il componente da lato consumatore .

   Questo è molto importante in quanto a volte ti dice che la tua API non ha senso da fuori.

Bene, cosa succede dopo aver scritto test unitari e test di integrazione più tardi?

Ho ottenuto ottime lezioni, un design chiaro, un buon costruttore, metodi brevi e coerenti, IoC ready ecc. Una volta che ho dato la mia classe / API ad un certo consumatore, ad es. sviluppatore dal team di integrazione o GUI, non è stato in grado di utilizzare la mia API in quanto sembra non logico, strano. Era solo confuso. Quindi ho riparato le API in base al suo punto di vista, ma ho anche dovuto riscrivere molti test perché sono stato spinto a cambiare i metodi ea volte anche il flusso su come utilizzare l'API.

Bene, cosa succede dopo aver scritto test di integrazione e unit test più tardi?

Ho ottenuto un flusso esatto, una 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:

1. Sviluppa lo scheletro di base del tuo codice
2. Scrivi test di integrazione che dicono se ha senso dal punto di vista del consumatore. Il caso d'uso di base è sufficiente per ora. Il test ovviamente non funziona.
3. Scrivi il codice insieme ai test unitari per ogni classe.
4. Scrivi il resto / mancante dei test di integrazione. Sarebbe meglio implementare questi test al punto # 3 come stai migliorando il tuo codice.

Tieni presente che ho fatto piccola presentazione a proposito test di unità / integrazione, vedere la diapositiva n. 21 in cui è descritto lo scheletro.

I Test delle unità vengono utilizzati per testare il bit di software testabile più piccolo possibile in un'applicazione e per verificarne la funzionalità. Ogni unità viene testata separatamente prima di amalgamarli in parti o componenti più grandi dell'applicazione.

Ecco dove arrivano Test di integrazione :
Testano queste parti appena create che consistono delle unità precedentemente testate durante il montaggio di queste parti insieme. Il caso migliore sarebbe scrivere i test a questo punto mentre si scrive l'applicazione stessa.

Tendo a vedere i test di integrazione come molto simili ai test unitari. In questo 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 cablato o che ho modificato leggermente 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 è di creare oggetti adattatori che traducono dal modo in cui la terza parte parla di ciò di cui l'applicazione ha bisogno e testa questi traduttori contro il vero sistema esterno. Se si esegue test-first o test-last, ritengo che sia meno importante rispetto ai normali test unitari perché

• Le informazioni sul design fornite da TDD non contano molto qui poiché il design è noto in anticipo e non c'è in genere nulla di particolarmente complicato, basta mappare le cose da un sistema all'altro.

• A seconda del modulo / sistema che si desidera affrontare, può richiedere molta esplorazione, configurazione, preparazione dei dati campione, che richiede tempo e non si adatta molto bene in un breve ciclo di feedback TDD.

Tuttavia, se ti senti davvero più a tuo agio nel costruire la tua scheda in modo incrementale in pochi passaggi sicuri, ti consiglio di andare prima per test, non può far male.

Puoi trovare esempi di questo approccio qui: link (sesto paragrafo) link

Quindi avrei accettato la prima risposta, ma è stata cancellata.
Per riassumere
In una determinata iterazione:

1. Scrivi test unitario
    
2. Scrivi il codice di produzione
    
3. Scrivi test di integrazione per testare le interazioni

Tieni a mente i test di integrazione mentre 1 e 2 per garantire la testabilità a livello di integrazione.

I test di integrazione non sono necessariamente scritti dall'inizio alla fine al punto 3 possono essere parzialmente scritti tra i passaggi 1 e 2.

I test unitari testano i blocchi discreti di codice all'interno del tuo progetto.
I test di integrazione testano il modo in cui il codice si interfaccia con un altro codice: in altre parole, testano l'interfaccia del codice.

Scrivi i test unitari durante lo sviluppo del codice dietro un'interfaccia.
Scrivi test di integrazione durante lo sviluppo dell'interfaccia o di qualsiasi codice che implementa l'interfaccia.

Ciò significa che a volte in alcuni progetti si scrivono test di integrazione, 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 molta logica interna

Tuttavia, se stai implementando un set di servizi REST o esegui il refactoring del modello dati e aggiungendo il supporto per le transazioni XA, inizierai a sviluppare i test di integrazione quasi immediatamente, perché la maggior parte del tuo lavoro è centrata sull'interfaccia , se si tratta dell'API REST o di come il programma utilizza il modello di dati.