Alternative per il test dell'unità

Questo è impossibile:

• A meno che non si limiti solo a funzioni pure, il valore del risultato potrebbe non catturare tutto ciò che fa una subroutine. Molte subroutine hanno effetti collaterali utili; questi effetti collaterali non vengono catturati nel valore del risultato. Ad esempio, C's printf restituisce il numero di caratteri scritti, ma la caratteristica più interessante di printf è che scrive qualcosa e che non viene catturato nel valore restituito.
• Non è possibile per i domini di grandi dimensioni mostrare il risultato per ogni valore nel dominio, ad es. un metodo Java foo(long, long, long) ha 2 ¹⁹² (~ 10 ⁶⁴ ) diversi input possibili, vicini al numero di particelle nell'universo, e anche se si avesse un 1000000 CPU core con 10 GHz che potrebbe mostrare un risultato per ogni ciclo di clock, ci vorrebbero ~ 20000000000000000000000000000000000 anni. Ancora peggio: la maggior parte dei domini è infinita, ad es. ci sono infinitamente molti String s, infinitamente molti Ruby Integer s, ecc.
• È impossibile determinare quale sia il risultato di una subroutine senza eseguirlo. (Questa è una variazione del Problema della funzione che è indecidibilmente dimostrabile.) Diamine, è persino impossibile determinare se anche ha un risultato o meno. (Questo è chiamato il Halting Problem ed è dimostrabilmente indecidibile.) Quindi, l'unico modo per generare i valori del risultato è eseguire la subroutine per ogni combinazione di possibili input, ma non hai idea di cosa sia la subroutine lo fa! Ad esempio, potrebbe formattare il tuo disco rigido. (E non puoi capire cosa fa, a causa del Problema della funzione .)

Dipende dalla tua applicazione. Se si scrive un convertitore e si dispone di una serie di set di input fissi, è possibile convertirli e segnalare eventuali differenze con un output di conversione precedente. Questo è un test prezioso. Se il tuo lavoro è per un cliente alla volta (il tuo progetto è per un set di dati di input), potrebbe funzionare.

Ma poi, sebbene sia un'alternativa, non fornirebbe le stesse informazioni dei test unitari. Sarebbe solo un test di regressione limitato.

la copertura del codice
• sarebbe sconosciuta;
• il ciclo di test potrebbe essere più lungo, eseguendo un ciclo completo i tuoi dati di test richiederanno tempo e faranno anche sviluppatori riluttante a farlo dopo ogni modifica;
• l'output di riferimento potrebbe contenere errori dall'inizio, non ne sarai mai sicuro.

Alla fine è una questione di percezione. Continui a vedere i test come un ingombrante compito post-sovraccarico che l'ambiente si aspetta da te, ma preferiresti saltare per poter andare avanti, o accetterai e abbraccerai i test di adattamento come parte del lavoro di sviluppo e della tua definizione personale di fatto?

A quanto pare i tuoi sviluppatori sentono la pressione per tagliare qualche angolo. Oppure scrivere dei test è solo un lavoro noioso per loro. Forse non ottengono "punti" per loro.

È necessario essere severi nella stesura dei test delle unità? Riscontriamo un sacco di bug che sarebbero stati catturati da appositi test unitari?

Per alcune applicazioni i test di unità sono inestimabili. Per altri potrebbero non essere altro che un ciuccio. Se si hanno requisiti chiari e precisi, difficilmente si può sbagliare. Se hai solo un grosso requisito e devi capire da solo tutti i piccoli passi, i test unitari non faranno molto per te. Semplicemente affermano che il tuo piccolo processo fa quello che avevi in mente, non se ti avvicinava di più al tuo obiettivo.

Quindi, come sempre, dipende. Pensa bene a ciò che conta per il tuo progetto, cosa ha senso testarlo e provarlo. I bug che vedi potrebbero essere un indicatore.

È possibile creare programmi corretti senza scrivere test, ma non si userebbe un sistema di test. Dovresti utilizzare un sistema di prova automatico, combinato con una specifica di comportamento. I migliori funzionano direttamente con il compilatore in modo che le tue specifiche siano parte del tuo codice, nello stile originariamente promosso da Liskov.

Nella vita reale, dovrai scrivere dei test. È possibile evitare molti test di basso livello includendo i precondizioni, la postcondizione e i controlli invarianti in tutto il codice di runtime di basso livello. In questo modo, qualsiasi test includerà il test del codice di basso livello in modo abbastanza completo. Tutti i test sono semplicemente un cattivo sostituto per il vero obiettivo, che è una prova di correttezza.