La scusa principale da parte dello sviluppatore per non avere un buon test unitario è "Il codice non è progettato in modo verificabile da unità". Sto cercando di capire quale tipo di design e codice non possono essere testati unitamente.
Diversi fattori potrebbero rendere il codice difficile da testare. In questo caso, il refactoring aiuta a migliorare il codice affinché sia testabile.
Alcuni esempi di codice che sarebbe probabilmente difficile da testare:
function pGetDp_U(int i, int i2, string sText) . Si noti che la mancanza di un'architettura chiara non rende il codice difficile da testare unitamente, poiché i test unitari riguardano piccole parti del codice. Un'architettura poco chiara avrebbe comunque un impatto negativo sull'integrazione e sui test di sistema.
Ci sono molte cose che rendono il codice difficile da testare. Per coincidenza molti di questi capita anche di rendere il codice difficile da mantenere:
Esempi comuni di persone con codice che non desiderano testare l'unità:
Usando un sistema di simulazione, tutti questi esempi possono essere testati su unità. È solo lavoro per impostare i sostituti simulati per le dipendenze interne.
Cose che davvero non possono essere testate da unità:
Ci sono alcune aree che possono rendere più difficile scrivere i test unitari. Tuttavia, sottolineo che ciò non significa che bisognerebbe scartare le tecniche utili semplicemente perché potrebbero aggiungere una certa complessità al test. Come con qualsiasi codifica tu dovresti fare la tua analisi per determinare se i benefici fuori i costi, e non accettare ciecamente ciò che alcuni ragazzi casuali inseriscono in rete.
Il costo per la maggior parte di queste spirale fuori controllo a meno che tu non sappia cosa stai facendo. Sfortunatamente, molti spesso non sanno come usare queste tecniche per mitigare cose come la complessità dei test.
Non esiste un codice che non possa essere testato. Vi sono, tuttavia, alcuni esempi di codice che è VERAMENTE, VERAMENTE difficile da testare (al punto che probabilmente non ne vale la pena):
Interazioni hardware - Se il codice manipola direttamente l'hardware (ad esempio, scrivendo su un registro per spostare un dispositivo fisico), l'unità di test potrebbe essere troppo difficile o costoso. Se si utilizza l'hardware reale per il test, può essere costoso ottenere un feedback appropriato nell'imbracatura di test (ancora più attrezzatura!), E se non lo si fa, si deve emulare il comportamento esatto degli oggetti fisici - nessun piccolo trucco in alcuni esempi.
Interazioni orologio - Di solito è più semplice, perché è quasi sempre possibile prendere in giro le funzioni dell'orologio di sistema in modo piuttosto banale. Ma quando non ci riesci, allora questi test diventano ingestibili - i test basati su tempo reale tendono a richiedere molto tempo per essere eseguiti, e nella mia esperienza tendono a essere molto fragili mentre i carichi di sistema rendono le cose più lunghe di quanto dovrebbero , causando guasti al test fantasma.
I miei tre gruppi principali per questo sono:
codice che si basa su servizi esterni
sistemi che non consentono ai tester di modificare lo stato indipendentemente dall'applicazione.
ambienti di test che non replicano la configurazione di produzione.
Questo è quello che ho sperimentato di più quando uno sviluppatore è diventato ingegnere del QA.
Leggi altre domande sui tag unit-testing