Test unitario e altre forme di test

Stranamente la migliore risposta a questa domanda è il principio di responsabilità singola.

Ma funziona solo se ci pensate nel modo in cui Zio Bob lo spiega oggi. Se pensi che SRP sia semplicemente "Fai una cosa", questa risposta probabilmente non ha senso.

The final version of the SRP is:

A module should be responsible to one, and only one, actor

Robert C. Martin - Clean Architecture

Per attore si intende un gruppo di persone che svolgono un singolo ruolo che ha un certo interesse nel codice. Queste persone dovrebbero essere le uniche persone in grado di costringerti a cambiare questo codice. Se il tuo codice risponde a due gruppi di persone che svolgono due ruoli diversi, il tuo codice serve due master.

Che mi ricorda i numeri magici. Si lo so. Aspetta.

Quando applichi il concetto Non ripetere te stesso, rifattori la duplicazione. Principalmente questa è una buona cosa, ma alcune duplicazioni esistono per una ragione. Potrei sostituire ogni variabile costante che è 3 con 3. Perché non io? Perché i nomi delle variabili rappresentano concetti diversi. Strutturalmente è ancora solo un 3 ma vogliamo più della struttura. Questo stesso concetto esiste anche in funzioni, classi, moduli e test.

Ciò di cui stai parlando è praticamente l'applicazione DRY ai diversi tipi di test. Questo va bene, ma non fare l'errore classico che le persone fanno quando applicano eccessivamente DRY. Non è la duplicazione strutturale che vogliamo eliminare. Vogliamo che ogni decisione vada in un solo posto. Se due decisioni separate sembrano identiche, non stritolarle e fingere di essere la stessa decisione. Va bene avere due vars costanti uguali a 3. È normale avere due metodi che contengono lo stesso codice. Va bene avere due tipi di test che testano la stessa cosa. Finché l'idea è diversa. Fintanto che l'attore al quale il codice è responsabile è diverso.

Lo so, è difficile. È molto più facile giudicare in base a come appare il codice, ma quello che ci interessa davvero è quello che serve. Ho parlato per l'ultima volta di questa idea qui .

Quindi non dirmi che il test è completo solo perché hai una copertura completa del codice. Questo non è il punto principale del test. Non lo sarà mai. Si suppone ci rassicuri che la base di codice fa quello che le persone si aspettano che faccia. E molte persone diverse hanno molte aspettative diverse.

Ora tutto ciò che è stato detto, se le persone sono aggrappate a vecchi test a causa di preoccupazioni che sono meglio affrontate da altri test, quindi scaricare i vecchi test. Altrimenti le cose si confondono.

Test unitari e test di integrazione esistono per diversi motivi.

I test unitari sono scritti dai programmatori per testare solo una funzione (responsabilità). Qui puoi applicare la regola SRP. I test dovrebbero essere veloci e devono essere facili da eseguire. Stanno correndo frequentemente per esempio dopo qualche correzione di bug nel codice.

Esiste un test di integrazione per eseguire diversi pezzi di sistema per vedere se funzionano bene insieme. Stanno usando risorse esterne come l'istanza di database in modo che siano più lunghe e potrebbero essere molto più difficili da avviare. Anche i test di integrazione dimostrano come funziona il sistema.

Quindi puoi avere test unitari e test di integrazione sia nella tua soluzione perché esistono per scopi diversi.

Possiamo pontificare su ciò che è e non è un test unitario per tutta l'eternità, cercando di rispondere a questa domanda.

Oppure, possiamo fare una bella risata guardando le immagini e guardando i video che appaiono quando cerchi due unit test nessun test di integrazione . Le immagini sono divertenti, ma portano anche a casa un messaggio serio, no non dovresti "ridurre la quantità di, o rimuovere completamente, i test funzionali e di integrazione" solo perché hai alcuni test unitari. Inoltre, nessun controllo automatico e di integrazione automatico rimuoverà mai la necessità per una persona di effettuare correttamente i test di esplorazione.

I test funzionali e di integrazione non possono essere minimizzati, anche con il migliore di tutti i team di sviluppatori / unità di test possibili. Il nuovo codice deve essere eseguito in un flusso reale (o il più vicino possibile ad esso) lungo tutto il codice che viene eseguito in un sistema. Sfortunatamente anche i migliori team di sviluppo eliminano ancora (intenzionalmente o involontariamente) le complicazioni del mondo reale per il bene dello sviluppo delle unità. Queste complicazioni possono esporre errori nel prodotto.

Ci sono una serie di aspetti nella tua domanda.

In primo luogo, i test unitari servono a dimostrare la correttezza del codice. La copertura del test mostra semplicemente quanto del codice viene eseguito. Avere una buona copertura del codice non significa avere test di unità ben scritti.

Per quanto riguarda se ci sono test che possono essere rimossi - ciò dipenderà piuttosto dalla presenza di duplicazioni. Solo gli sviluppatori sarebbero in grado di rispondere a questo, anche se alcuni strumenti possono aiutare.

Continuous Deployment (CD) significa semplicemente che il codice viene eliminato una volta che è stato distribuito. Questo non ha nulla a che fare con i test, anche se sarebbe inerte sul gestore di build per consentire che ciò accada se i test non sono passati!

Per quanto riguarda il fatto che questo accada solo se questa unit test passa, questa è di nuovo una domanda per il build manager. Alcuni consentono di eseguire solo test unitari mentre altri eseguono anche test di integrazione. Di solito dipende dal volume di produzione. Se i build sono costantemente in coda perché i test di integrazione sono in esecuzione, potrebbero essere propensi a impostare la build per eseguire solo test unitari o avere una build separata che esegua i test di integrazione meno frequentemente (forse durante la notte o settimanalmente ecc.)