È sufficiente utilizzare i test di accettazione e integrazione anziché i test unitari?

Breve introduzione a questa domanda. Ho usato TDD e ultimamente BDD per oltre un anno. Uso tecniche come il deridere per rendere più efficiente la scrittura dei miei test. Ultimamente ho avviato un progetto personale per scrivere un piccolo programma di gestione del denaro per me stesso. Dato che non avevo un codice legacy, era il progetto perfetto per iniziare con TDD. Purtroppo non ho provato così tanto la gioia di TDD. Mi ha persino rovinato così tanto il divertimento che ho rinunciato al progetto.

Qual'era il problema? Bene, ho usato l'approccio simile a TDD per consentire ai test / requisiti di evolvere la progettazione del programma. Il problema era che oltre la metà del tempo di sviluppo per quanto riguarda i test di scrittura / refactoring. Quindi alla fine non volevo implementare altre funzionalità perché avrei dovuto refactoring e scrivere a molti test.

Al lavoro ho un sacco di codice legacy. Qui scrivo sempre più test di integrazione e accettazione e meno test unitari. Questo non sembra essere un cattivo approccio poiché i bug sono per lo più rilevati dai test di accettazione e integrazione.

La mia idea era che alla fine avrei potuto scrivere più test di integrazione e accettazione rispetto ai test unitari. Come ho detto per il rilevamento di bug, i test unitari non sono migliori dei test di integrazione / accettazione. Anche i test unitari sono validi per il design. Da quando ne scrivevo molti, le mie lezioni sono sempre progettate per essere testabili. Inoltre, l'approccio che consente ai test / requisiti di guidare la progettazione conduce, nella maggior parte dei casi, a una progettazione migliore. L'ultimo vantaggio dei test unitari è che sono più veloci. Ho scritto abbastanza test di integrazione per sapere che possono essere quasi veloci quanto i test unitari.

Dopo aver guardato attraverso il web ho scoperto che ci sono idee molto simili alle mie menzionate qua e là . Cosa ne pensi di quest idea?

modificare

Rispondendo alle domande un esempio in cui il design era buono, ma avevo bisogno di un enorme refactoring per il prossimo requisito:

Inizialmente c'erano alcuni requisiti per eseguire determinati comandi. Ho scritto un parser di comandi estensibile - che analizzava i comandi da una sorta di prompt dei comandi e chiamava quello corretto sul modello. Il risultato è stato rappresentato in una classe del modello di vista:

Non c'era niente di sbagliato qui. Tutte le classi erano indipendenti l'una dall'altra e potevo facilmente aggiungere nuovi comandi, mostrare nuovi dati.

Il requisito successivo era che ogni comando dovesse avere una propria rappresentazione della vista - una sorta di anteprima del risultato del comando. Ho riprogettato il programma per ottenere un design migliore per il nuovo requisito:

Anche questo era buono perché ora ogni comando ha il suo modello di vista e quindi la sua anteprima.

Il fatto è che il parser dei comandi è stato modificato per utilizzare un'analisi dei comandi basata su token ed è stato rimosso dalla sua capacità di eseguire i comandi. Ogni comando ha il proprio modello di visualizzazione e il modello di visualizzazione dati conosce solo il modello di visualizzazione comandi corrente che non conosce i dati che devono essere mostrati.

Tutto quello che volevo sapere a questo punto è, se il nuovo design non ha violato alcun requisito esistente. Non ho dovuto cambiare QUALUNQUE del mio test di accettazione. Ho dovuto refactoring o eliminare quasi OGNI test unitario, che era un enorme mucchio di lavoro.

Quello che volevo mostrare qui è una situazione comune che si è verificata spesso durante lo sviluppo. Non ci sono stati problemi con il vecchio o il nuovo design, sono semplicemente cambiati naturalmente con i requisiti: come l'ho capito, questo è uno dei vantaggi di TDD, che il design si evolve.

Conclusione

Grazie per tutte le risposte e discussioni. In sintesi di questa discussione ho pensato a un approccio che testerò con il mio prossimo progetto.

• Prima di tutto scrivo tutti i test prima di implementare qualcosa come ho sempre fatto.
• Per esigenze scrivo inizialmente alcuni test di collaudo che testano l'intero programma. Quindi scrivo alcuni test di integrazione per i componenti in cui devo implementare il requisito. Se esiste un componente che lavora a stretto contatto con un altro componente per implementare questo requisito, scriverei anche alcuni test di integrazione in cui entrambi i componenti vengono testati insieme. Ultimo ma non meno importante se devo scrivere un algoritmo o qualsiasi altra classe con un'alta permutazione - ad esempio un serializzatore - scriverei test unitari per queste classi particolari. Tutte le altre classi non sono testate ma eventuali test unitari.
• Per i bug il processo può essere semplificato. Normalmente un bug è causato da uno o due componenti. In questo caso, scriverei un test di integrazione per i componenti che verifica il bug. Se fosse correlato a un algoritmo, scriverei solo un test unitario. Se non è facile rilevare il componente in cui si verifica il bug, scriverei un test di accettazione per individuare il bug - questa dovrebbe essere un'eccezione.

Paragona arance e mele.

Test di integrazione, test di accettazione, test unitari, test comportamentali: sono tutti test e ti aiuteranno a migliorare il tuo codice ma sono anche abbastanza diversi.

A mio avviso, supererò ciascuno dei diversi test e, spero, spiegherò perché è necessario un mix di tutti:

Test di integrazione:

Semplicemente, verifica che le diverse parti del sistema si integrino correttamente, ad esempio, forse simuli una richiesta di servizio Web e verifichi che il risultato ritorni. Generalmente userei dati statici (ish) reali e dipendenze derise per assicurarmi che possano essere verificati in modo coerente.

Test di accettazione:

Un test di accettazione dovrebbe essere direttamente correlato a un caso d'uso aziendale. Può essere enorme ("gli scambi sono inviati correttamente") o minuscolo ("il filtro filtra correttamente un elenco") - non importa; ciò che conta è che dovrebbe essere esplicitamente legato a un requisito specifico dell'utente. Mi piace concentrarmi su questi aspetti per lo sviluppo guidato dai test perché significa che abbiamo un buon manuale di riferimento dei test per le storie degli utenti che dev e qa devono verificare.

Test unitari:

Per piccole unità discrete di funzionalità che possono o non possono costituire da sole una singola storia utente - ad esempio, una storia utente che dice che recuperiamo tutti i clienti quando accediamo a una pagina Web specifica può essere un test di accettazione (simulare di colpire il Web pagina e verifica della risposta) ma può contenere anche diversi test unitari (verifica che le autorizzazioni di sicurezza siano verificate, verifica che la connessione al database richieda correttamente, verifica che qualsiasi codice che limiti il ​​numero di risultati sia eseguito correttamente) - questi sono tutti "test unitari" che non sono un test di accettazione completo.

Test comportamentali:

Definire quale dovrebbe essere il flusso di un'applicazione nel caso di un input specifico. Ad esempio, "quando non è possibile stabilire una connessione, verificare che il sistema ritenti la connessione". Ancora una volta, è improbabile che questo sia un test di accettazione completo, ma ti consente comunque di verificare qualcosa di utile.

Questi sono tutti secondo me attraverso una grande esperienza nella scrittura di test; Non mi piace concentrarmi sugli approcci dei libri di testo, ma piuttosto su ciò che dà valore ai tuoi test.

TL; DR: Finché soddisfa le tue esigenze, sì.

Faccio lo sviluppo dello sviluppo guidato dai test di accettazione (ATDD) da molti anni. Può avere molto successo. Ci sono alcune cose di cui essere consapevoli.

• I test unitari aiutano davvero a rafforzare il COI. Senza test unitari, gli sviluppatori devono assicurarsi che soddisfino i requisiti di un codice ben scritto (in quanto i test unitari guidano un codice ben scritto)
• Possono essere più lenti e avere falsi fallimenti se in realtà stai usando risorse che sono tipicamente derise.
• Il test non individua il problema specifico come farebbero i test unitari. È necessario effettuare ulteriori indagini per correggere gli errori di test.

Ora i vantaggi

• Copertura del test molto migliore, copre i punti di integrazione.
• Garantisce che il sistema nel suo insieme soddisfi i criteri di accettazione, che è il punto centrale dello sviluppo del software.
• Rende i refactor di grandi dimensioni molto più facili, più veloci ed economici.

Come sempre spetta a te fare l'analisi e capire se questa pratica è appropriata per la tua situazione. A differenza di molte persone, non penso che esista una risposta giusta idealizzata. Dipenderà dalle tue esigenze e esigenze.

Bene, ho usato l'approccio simile a TDD per consentire ai test / requisiti di evolvere la progettazione del programma. Il problema era che oltre la metà del tempo di sviluppo per quanto riguarda i test di scrittura / refactoring

I test unitari funzionano meglio quando l'interfaccia pubblica dei componenti per cui vengono utilizzati non cambia troppo spesso. Ciò significa che quando i componenti sono già progettati correttamente (ad esempio, seguendo i principi SOLID).

Quindi credere che un buon design si "evolva" semplicemente "lanciando" molti test unitari su un componente è un errore. TDD non è un "insegnante" per un buon design, può solo aiutare un po 'a verificare che alcuni aspetti del design siano buoni (specialmente la testabilità).

Quando i tuoi requisiti cambiano e devi cambiare gli interni di un componente, e questo interromperà il 90% dei tuoi test unitari, quindi dovrai riformattarli molto spesso, quindi il design molto probabilmente non è stato così buono.

Quindi il mio consiglio è: pensa al design dei componenti che hai creato e come puoi renderli più seguendo il principio aperto / chiuso. L'idea di quest'ultimo è quella di assicurarsi che le funzionalità dei componenti possano essere estese in seguito senza modificarle (e quindi non interrompere l'API del componente utilizzata dai test delle unità). Tali componenti possono (e dovrebbero essere) coperti da test unit test e l'esperienza non dovrebbe essere così dolorosa come l'hai descritta.

Quando non è possibile elaborare immediatamente tale progetto, i test di accettazione e integrazione potrebbero essere davvero un inizio migliore.

EDIT: A volte il design dei componenti può andare bene, ma il design dei test unitari può causare problemi . Esempio semplice: si desidera testare il metodo "MyMethod" della classe X e scrivere

    var x= new X();
    Assert.AreEqual("expected value 1" x.MyMethod("value 1"));
    Assert.AreEqual("expected value 2" x.MyMethod("value 2"));
    // ...
    Assert.AreEqual("expected value 500" x.MyMethod("value 500"));

(supponiamo che i valori abbiano un qualche tipo di significato).

Supponiamo inoltre che nel codice di produzione vi sia una sola chiamata a X.MyMethod. Ora, per un nuovo requisito, il metodo "MyMethod" richiede un parametro aggiuntivo (ad esempio, qualcosa di simile context), che non può essere omesso. Senza test unitari, si dovrebbe refactificare il codice chiamante in un solo posto. Con i test unitari, si devono refactoring 500 posti.

Ma la causa qui non è che l'unità si testa da sola, è solo il fatto che la stessa chiamata a "X.MyMethod" si ripete ancora e ancora, non seguendo rigorosamente il principio "Don't Repeat Yourself (DRY). Quindi la soluzione qui è quello di mettere i dati di test e i relativi valori previsti in un elenco ed eseguire le chiamate a "MyMethod" in un ciclo (o, se lo strumento di test supporta i cosiddetti "test di unità di dati", per utilizzare quella funzione). il numero di posti da cambiare nei test unitari quando la firma del metodo cambia in 1 (invece di 500).

Nel tuo caso reale, la situazione potrebbe essere più complessa, ma spero che tu abbia l'idea - quando i tuoi test unitari utilizzano un'API dei componenti per la quale non sai se potrebbe diventare soggetto a modifiche, assicurati di ridurre il numero di chiamate a quell'API al minimo.

Sì, certo che lo è.

Considera questo:

• un test unitario è un piccolo test mirato che esercita un piccolo codice. Ne scrivi molti per ottenere una copertura decente del codice, in modo che tutti (o la maggior parte dei bit scomodi) vengano testati.
• un test di integrazione è un test ampio e ampio che esercita un'ampia superficie del codice. Ne scrivi pochi per ottenere una copertura decente del codice, in modo che tutti (o la maggior parte dei bit scomodi) vengano testati.

Vedi la differenza complessiva ....

Il problema riguarda la copertura del codice, se è possibile ottenere un test completo di tutto il codice utilizzando i test di integrazione / accettazione, non si verifica alcun problema. Il tuo codice è stato testato. Questo è l'obiettivo.

Penso che potresti aver bisogno di confonderli, poiché ogni progetto basato su TDD richiederà alcuni test di integrazione solo per assicurarsi che tutte le unità funzionino davvero bene insieme (so per esperienza che una base di codice testata da unità al 100% non funziona necessariamente quando li metti tutti insieme!)

Il problema dipende davvero dalla facilità di test, debug degli errori e risoluzione degli errori. Alcune persone trovano che i loro test unitari siano molto bravi in ​​questo, sono piccoli e semplici e gli errori sono facili da vedere, ma lo svantaggio è che devi riorganizzare il tuo codice per adattarlo agli strumenti di unit test e scriverne molti. Un test di integrazione è più difficile da scrivere per coprire un sacco di codice e probabilmente dovrai usare tecniche come la registrazione per eseguire il debug di tutti gli errori (anche se, direi che devi farlo comunque, non puoi fallire i test unitari quando sul posto!).

Ad ogni modo, ottieni comunque un codice testato, devi solo decidere quale meccanismo si adatta meglio a te. (Vorrei andare con un po 'di un mix, testare gli algoritmi complessi e integrare test il resto).

Penso che sia un'idea orribile.

Poiché i test di accettazione e quelli di integrazione toccano parti più ampie del codice per testare un obiettivo specifico, avranno bisogno di più refactoring nel tempo, non di meno. Peggio ancora, poiché coprono ampie sezioni del codice, aumentano il tempo impiegato a rintracciare la causa principale poiché hai un'area più ampia da cui cercare.

No, di solito dovresti scrivere più test unitari a meno che tu non abbia un'app dispari con un'interfaccia utente del 90% o qualcos'altro che è scomodo per test unitari. Il dolore che stai incontrando non proviene dai test unitari, ma dal primo sviluppo del test. In genere, dovresti dedicare solo 1/3 del tuo tempo alla maggior parte dei test di scrittura. Dopotutto, sono lì per servirti, non viceversa.

La "vittoria" con TDD è che una volta che i test sono stati scritti, possono essere automatizzati. Il rovescio della medaglia è che può consumare una parte significativa del tempo di sviluppo. Se questo effettivamente rallenta l'intero processo è discutibile. L'argomento è che il test iniziale riduce il numero di errori da correggere alla fine del ciclo di sviluppo.

È qui che entra in gioco BDD poiché i comportamenti possono essere inclusi nel test unitario, quindi il processo è per definizione meno astratto e più tangibile.

Chiaramente, se fosse disponibile una quantità infinita di tempo, faresti il ​​maggior numero possibile di test su varie varietà. Tuttavia, il tempo è generalmente limitato e i test continui sono convenienti solo fino a un certo punto.

Tutto ciò porta alla conclusione che i test che forniscono il massimo valore dovrebbero essere in primo piano nel processo. Questo di per sé non favorisce automaticamente un tipo di test rispetto a un altro - più che ogni caso deve essere preso nel merito.

Se stai scrivendo un widget da riga di comando per uso personale, saresti interessato principalmente ai test unitari. Considerando che un servizio web dice, richiederebbe una notevole quantità di test di integrazione / comportamentale.

Mentre la maggior parte dei tipi di test si concentra su quella che potrebbe essere definita la "linea da corsa", ovvero testare ciò che è richiesto oggi dal business, i test unitari sono eccellenti per eliminare i bug sottili che potrebbero emergere nelle successive fasi di sviluppo. Poiché questo è un vantaggio che non può essere facilmente misurato, viene spesso trascurato.

L'ultimo vantaggio dei test unitari è che sono più veloci. Ho scritto abbastanza test di integrazione per sapere che possono essere quasi veloci quanto i test unitari.

Questo è il punto chiave e non solo "l'ultimo vantaggio". Quando il progetto diventa sempre più grande, i test di accettazione dell'integrazione stanno diventando sempre più lenti. E qui, intendo così lentamente che smetterai di eseguirli.

Naturalmente, anche i test unitari stanno diventando più lenti, ma sono comunque più veloci dell'ordine di grandezza. Ad esempio, nel mio precedente progetto (c ++, circa 600 kLOC, 4000 unit test e 200 test di integrazione), ci sono voluti circa un minuto per eseguire tutti e più di 15 per eseguire test di integrazione. Per costruire ed eseguire i test unitari per la parte da modificare, occorrerebbero in media meno di 30 secondi. Quando puoi farlo così in fretta, ti consigliamo di farlo sempre.

Giusto per chiarire: non dico di non aggiungere test di integrazione e accettazione, ma sembra che tu abbia fatto TDD / BDD in modo sbagliato.

Anche i test unitari sono validi per il design.

Sì, progettare pensando alla testabilità renderà il progetto migliore.

Il problema era che oltre la metà del tempo di sviluppo per quanto riguarda i test di scrittura / refactoring. Quindi alla fine non volevo implementare altre funzionalità perché avrei dovuto refactoring e scrivere a molti test.

Bene, quando i requisiti cambiano, devi cambiare il codice. Direi che non hai finito il tuo lavoro se non hai scritto test unitari. Ma questo non significa che dovresti avere una copertura del 100% con i test unitari, non è questo l'obiettivo. Alcune cose (come la GUI o l'accesso a un file, ...) non sono nemmeno pensate per essere testate in unità.

Il risultato è una migliore qualità del codice e un altro livello di test. Direi che ne vale la pena.

Avevamo anche diversi test di accettazione per 1000 e ci sarebbe voluta un'intera settimana per eseguire tutti.