È ragionevole non scrivere unit test perché tendono a essere commentati in seguito o perché i test di integrazione sono più preziosi?

Stavo discutendo dei test di unità / integrazione con un collega e ha presentato un caso interessante contro la scrittura di test di unità. Sono un grande sostenitore di test di unità (principalmente JUnit), ma sono interessato a sentire i commenti degli altri, mentre ha fatto alcuni punti interessanti.

Per riassumere i suoi punti:

• Quando si verificano importanti modifiche al codice (nuova serie di POJO, refactoring delle applicazioni principali, ecc.), I test unitari tendono a essere commentati anziché rielaborati.
• È meglio dedicare tempo ai test di integrazione relativi ai casi d'uso, che rendono i test di portata minore meno / per niente importanti.

Pensi su questo? Sono ancora pro-unit test (come lo vedo costantemente produrre codice migliorato), anche se i test di integrazione sembrano almeno altrettanto preziosi.

Tendo a schierarmi con il tuo amico perché troppo spesso i test unitari mettono alla prova le cose sbagliate .

I test unitari non sono intrinsecamente negativi. Ma spesso testano i dettagli di implementazione piuttosto che il flusso di input / output. Si finisce con test completamente inutili quando questo accade. La mia regola è che un buon test unitario ti dice che hai appena rotto qualcosa; un cattivo test unitario ti dice semplicemente che hai appena cambiato qualcosa.

Un esempio al di sopra della mia testa è un test che è stato nascosto in WordPress qualche anno fa. La funzionalità testata ruotava attorno a filtri che si chiamavano l'un l'altro e i test stavano verificando che i callback sarebbero stati chiamati nell'ordine corretto. Invece di (a) eseguire la catena per verificare che i callback vengano chiamati nell'ordine previsto, i test si sono concentrati sulla (b) lettura di uno stato interno che probabilmente non avrebbe dovuto essere esposto all'inizio. Cambia gli interni e (b) diventa rosso; mentre (a) diventa rosso solo se le modifiche interne infrangono il risultato atteso mentre lo fanno. (b) è stato chiaramente un test inutile a mio avviso.

Se hai una classe che espone alcuni metodi al mondo esterno, la cosa corretta da testare a mio avviso sono solo questi ultimi . Se testate anche la logica interna, potreste finire per esporre la logica interna al mondo esterno, usando metodi di test contorti o con una litania di unit test che si interrompono invariabilmente ogni volta che volete cambiare qualcosa.

Detto questo, sarei sorpreso se il tuo amico è critico nei confronti dei test unitari di per sé come sembri suggerire. Piuttosto, vorrei dire che è pragmatico. Ossia, ha osservato che i test unitari che vengono scritti sono praticamente inutili nella pratica. Citando: "i test unitari tendono ad essere commentati piuttosto che rielaborati". Per me c'è un messaggio implicito lì dentro - se tendono ad avere bisogno di essere rielaborate è perché tendono a succhiare. Partendo dal presupposto, la seconda proposta segue: gli sviluppatori perderebbero meno tempo a scrivere codice che è più difficile sbagliare, ad esempio i test di integrazione.

In quanto tale, non si tratta di essere migliori o peggiori. È solo che uno è molto più facile sbagliare, e in effetti molto spesso nella pratica.

Quando si verificano importanti cambiamenti di codice, i test unitari tendono ad essere commentati piuttosto che rielaborati.

Con un gruppo indisciplinato di programmatori di cowboy che pensano che tutti i test che diventano "verdi" siano soddisfatti quando si commentano tutti i test esistenti: ovviamente. Rielaborare i test unitari richiede la stessa disciplina di scriverli in prima persona, quindi quello su cui devi lavorare qui è la "definizione del fatto" del tuo team.

È meglio dedicare tempo ai test di integrazione che coprono casi d'uso che rendono i test di portata minore meno / per niente importanti.

Questo non è né completamente sbagliato né completamente giusto. Lo sforzo per scrivere utili test di integrazione dipende molto dal tipo di software che stai scrivendo. Se hai un software in cui i test di integrazione possono essere scritti con la stessa facilità dei test unitari, funzionano ancora velocemente e ti offrono una buona copertura del tuo codice, quindi il tuo collega ha ragione. Ma per molti sistemi ho visto che questi tre punti non possono essere facilmente soddisfatti dai test di integrazione, ecco perché dovresti cercare di fare anche test unitari.

Non so che accetto gli argomenti del tuo collega.

1. Se i test unitari vengono commentati, è perché qualcuno è pigro. Non è colpa dei test unitari. E se inizi a usare lazy come scusa, puoi litigare con qualsiasi pratica che richiede un piccolo sforzo.
2. Se lo stai facendo nel modo giusto, i test unitari non devono richiedere molto tempo. Non ti impediscono di fare lavori più importanti. Se siamo tutti d'accordo sul fatto che correggere il codice non funzionante è più importante di ogni altra cosa, un test unitario è dannatamente importante. È un modo semplice per testare le condizioni postali. Senza di essa, come fai a sapere di aver soddisfatto le garanzie delle condizioni postali? E se non l'hai fatto, il tuo codice è rotto.

Esistono altri argomenti più convincenti contro i test unitari. Beh, non esattamente contro di loro. Inizia con i danni di progettazione indotti dal test di DHH . È uno scrittore divertente, quindi leggilo. Cosa ne ho preso:

Se si apportano grandi modifiche alla progettazione per adattarsi ai test unitari, potrebbero ostacolare altri obiettivi nel progetto. Se possibile, chiedi a una persona imparziale quale approccio è più facile da seguire. Se il tuo codice altamente testabile è difficile da capire, potresti perdere tutti i vantaggi ottenuti dai test unitari. Il sovraccarico cognitivo di troppa astrazione ti rallenta e rende più facili gli errori che perdono. Non lo sconto.

Se vuoi diventare sfumato e filosofico, ci sono molte grandi risorse:

• I test di Ian Bicking sono considerati dannosi (i test non sono sufficienti. I test non rendono il codice bello.)
• La crescente copertura del codice di Dan Manges può essere dannosa (L'uso della copertura del codice come metrica non ti dice se stai facendo qualcosa di utile.)
• Quindi ci sono buoni argomenti per non scrivere unit test? [chiuso] da Stack Overflow. (Overconfidence, il costo non è riconosciuto, non trova i bug insidiosi, non un sostituto per il bellissimo codice [kinda like Bicking], ecc ...)

Quando si verificano importanti modifiche al codice (nuova serie di POJO, refactoring delle applicazioni principali, ecc.), I test unitari tendono a essere commentati anziché rielaborati.

Non farlo. Se trovi qualcuno che lo fa, uccidilo e assicurati che non si riproduca, poiché i suoi figli potrebbero ereditare quel gene difettoso. La chiave per come la vedo mentre guardo i programmi televisivi CSI è di spargere un sacco di campioni di DNA fuorvianti ovunque. In questo modo inquini la scena del crimine con così tanto rumore che, data la natura costosa e che richiede tempo del test del DNA, la probabilità che te la fissino è astronomicamente bassa.

i test unitari tendono ad essere commentati piuttosto che rielaborati.

A quel punto il processo di revisione del codice dice "vai a correggere i test unitari" e questo non è più un problema :-) Se il tuo processo di revisione del codice non rileva questo tipo di grave difetto nel codice inviato, allora questo è il problema.

Quando si verificano importanti modifiche al codice (nuova serie di POJO, refactoring delle applicazioni principali, ecc.), I test unitari tendono a essere commentati anziché rielaborati.

Cerco sempre di mantenere separati il ​​refactoring e il cambio di funzionalità. Quando devo fare entrambe le cose, di solito commetto prima il refactoring.

Quando si effettua il refactoring senza modificare la funzionalità, si suppone che i test unitari esistenti contribuiscano a garantire che il refactoring non interrompa accidentalmente la funzionalità. Quindi per un tale impegno considererei la disabilitazione o la rimozione dei test unitari come un segnale di avvertimento importante. A qualsiasi sviluppatore che lo fa dovrebbe essere detto di non farlo quando il codice viene rivisto.

È possibile che i cambiamenti che non cambiano la funzionalità causino il fallimento dei test unitari a causa di test unitari difettosi. Se si capisce il codice che si sta modificando, la causa di tali guasti ai test unitari è di solito immediatamente ovvia e facile da risolvere.

Ad esempio, se una funzione accetta tre argomenti, un unit test che copre l'interazione tra i primi due argomenti per la funzione potrebbe non aver avuto cura di fornire un valore valido per il terzo argomento. Questo difetto nel test unitario può essere esposto da un refactoring del codice testato, ma è facile da risolvere se si capisce che cosa deve fare il codice e cosa sta testando il test unitario.

Quando si modificano le funzionalità esistenti, di solito sarà necessario modificare anche alcuni test unitari. In questo caso i test unitari aiutano a garantire che il codice cambi la funzionalità come previsto e che non abbia effetti collaterali indesiderati.

Quando si correggono i bug o si aggiungono nuove funzionalità, di solito è necessario aggiungere più unit test. Per quelli può essere utile eseguire prima i test unitari e successivamente la correzione dei bug o le nuove funzionalità. Ciò semplifica la verifica che i nuovi test unitari non siano stati superati con il codice precedente ma siano passati con il codice più recente. Questo approccio non è del tutto privo di inconvenienti, quindi esistono anche argomenti a favore del commit simultaneo di nuovi test unitari e aggiornamenti del codice.

È meglio dedicare tempo ai test di integrazione relativi ai casi d'uso, che rendono i test di portata minore meno / per niente importanti.

C'è qualche elemento di verità in questo. Se è possibile ottenere una copertura degli strati inferiori dello stack software con test mirati agli strati superiori dello stack software, i test potrebbero essere più utili durante il refactoring del codice.

Non credo che troverai un accordo sull'esatta distinzione tra un test unitario e un test di integrazione. E non mi preoccuperei se hai un caso di test che uno sviluppatore chiama un unit test e un altro chiama un test di integrazione, purché possano concordare che si tratta di un utile test case.

Vengono eseguiti test di integrazione per verificare se il sistema si comporta come dovrebbe, il che ha sempre valore commerciale. I test unitari non sempre lo fanno. I test unitari potrebbero testare il codice morto, ad esempio.

Esiste una filosofia di test che afferma che qualsiasi test che non ti fornisce informazioni è uno spreco. Quando un pezzo di codice non viene elaborato, i suoi test unitari diventano sempre (o quasi sempre) verdi, fornendo poche o nessuna informazione.

Ogni metodo di prova sarà incompleto. Anche se ottieni una copertura del 100% con alcune metriche, non stai ancora esaminando quasi tutti i possibili set di dati di input. Quindi, non pensare che i test unitari siano magici.

Ho visto spesso l'affermazione che avere test unitari migliora il tuo codice. A mio avviso, i miglioramenti apportati dai test unitari al codice stanno costringendo le persone che non sono abituate a suddividere il proprio codice in piccoli pezzi ben ponderati. Se ti abitui a progettare il tuo codice in piccoli pezzi ben ponderati normalmente, potresti scoprire che non hai bisogno di unit test per costringerti a farlo più.

A seconda di quanto pesantemente test unitario e quanto è grande il tuo programma, potresti finire con un numero enorme di test unitari. In tal caso, i grandi cambiamenti diventano più difficili. Se una grande modifica provoca molti test unitari falliti, puoi rifiutare di apportare la modifica, fare molto lavoro per sistemare molti test o buttare via i test. Nessuna delle scelte è l'ideale.

I test unitari sono uno strumento nella casella degli strumenti. Sono lì per servirti, non viceversa. Assicurati di uscire da loro almeno quanto hai messo.

I test unitari non sono sicuramente il proiettile d'argento che alcuni sostenitori affermano di essere. Ma in generale hanno un rapporto costi / benefici molto positivo. Non renderanno il tuo codice "migliore", forse più modulare. "migliore" ha molti più fattori di ciò che implica la "testabilità". Ma assicureranno che funziona in tutti i casi e gli usi a cui hai pensato, ed elimineranno la maggior parte dei tuoi bug (probabilmente i più banali).

Il più grande vantaggio dei test unitari è che rendono il codice più flessibile e resiliente alle modifiche. Puoi refactoring o aggiungere funzionalità ed essere abbastanza sicuro di non aver rotto nulla. Questo da solo li rende utili per la maggior parte dei progetti.

Facendo riferimento ai punti sollevati dal tuo amico:

1. Se l'aggiunta di POJO interrompe i test unitari, probabilmente sono scritti molto male. I POJO sono di solito la lingua che stai usando per parlare del tuo dominio e i problemi che stai risolvendo, cambiandoli ovviamente significano la tua intera logica aziendale, e probabilmente il codice di presentazione deve cambiare. Non puoi aspettarti che cosa assicuri che quelle parti del tuo programma non cambino ...

2. Lamentarsi che i test unitari siano negativi, perché le persone li commentano, è come lamentarsi che le cinture di sicurezza siano cattive perché le persone non le indossano. Se uno commenta test del codice e rompe qualcosa, dovrebbe finire in una conversazione molto seria e spiacevole con il suo capo ...

3. I test di integrazione sono di gran lunga superiori ai test unitari. nessuna domanda. soprattutto se stai testando un prodotto. Ma scrivere buoni test di integrazione completi, che ti daranno lo stesso valore, la copertura e la certezza della correttezza che ti danno i test unitari, è incredibilmente difficile.

Posso solo pensare a un argomento contro i test unitari ed è piuttosto debole.

I test unitari mostrano la maggior parte del loro valore quando si refactoring o si modifica il codice in una fase successiva. Noti una notevole riduzione del tempo necessario per aggiungere funzionalità e assicurarti di non aver rotto nulla.

Tuttavia: in primo luogo c'è un costo (piccolo) per la scrittura dei test.

Pertanto: se un progetto è abbastanza breve e non richiede manutenzione / aggiornamenti continui, è possibile che il costo della scrittura dei test superi i loro benefici.