È.
Anche se si eseguono solo test unitari, non è insolito avere più codice nei test rispetto al codice effettivamente testato. Non c'è niente di sbagliato in questo.
Prendi in considerazione un codice semplice:
public void SayHello(string personName)
{
if (personName == null) throw new NullArgumentException("personName");
Console.WriteLine("Hello, {0}!", personName);
}
Quali sarebbero i test? Ci sono almeno quattro semplici casi da testare qui:
Il nome della persona è null. L'eccezione viene effettivamente lanciata? Sono almeno tre righe di codice di prova da scrivere.
Il nome della persona è "Jeff". Riceviamo una "Hello, Jeff!"risposta? Sono quattro righe di codice di prova.
Il nome della persona è una stringa vuota. Quale output ci aspettiamo? Qual è l'output effettivo? Domanda a margine: corrisponde ai requisiti funzionali? Ciò significa che altre quattro righe di codice per l'unità di test.
Il nome della persona è abbastanza breve per una stringa, ma troppo lungo per essere combinato con "Hello, "il punto esclamativo. Cosa succede? ¹
Ciò richiede molto codice di prova. Inoltre, i pezzi di codice più elementari richiedono spesso un codice di installazione che inizializza gli oggetti necessari per il codice in prova, che spesso porta anche alla scrittura di matrici e simulazioni, ecc.
Se il rapporto è molto grande, nel qual caso è possibile verificare alcune cose:
Esiste una duplicazione del codice durante i test? Il fatto che sia un codice di test non significa che il codice debba essere duplicato (copia-incolla) tra test simili: tale duplicazione renderà difficile il mantenimento di tali test.
Ci sono test ridondanti? Come regola generale, se si rimuove un test unitario, la copertura del ramo dovrebbe diminuire. In caso contrario, potrebbe indicare che il test non è necessario, poiché i percorsi sono già coperti da altri test.
Stai testando solo il codice che dovresti testare? Non è previsto il test del framework sottostante delle librerie di terze parti, ma esclusivamente il codice del progetto stesso.
Con i test del fumo, i test di sistema e di integrazione, i test funzionali e di collaudo e i test di stress e di carico, aggiungi ancora più codice di test, quindi avere quattro o cinque LOC di test per ogni LOC del codice reale non è qualcosa di cui dovresti preoccuparti.
Una nota su TDD
Se sei preoccupato per il tempo necessario per testare il tuo codice, è possibile che tu stia sbagliando, ovvero prima il codice, poi i test. In questo caso, TDD può aiutarti incoraggiandoti a lavorare in iterazioni di 15-45 secondi, passando da codice a test. Secondo i fautori di TDD, accelera il processo di sviluppo riducendo sia il numero di test che è necessario eseguire sia, soprattutto, la quantità di codice aziendale da scrivere e soprattutto riscrivere per i test.
¹ Sia n sia la lunghezza massima di una stringa . Possiamo chiamare SayHelloe passare per riferimento una stringa di lunghezza n - 1 che dovrebbe funzionare bene. Ora, al Console.WriteLinepasso, la formattazione dovrebbe finire con una stringa di lunghezza n + 8, che comporterà un'eccezione. Forse, a causa dei limiti di memoria, anche una stringa contenente n / 2 caratteri comporterà un'eccezione. La domanda che ci si dovrebbe porre è se questo quarto test è un test unitario (sembra uno, ma può avere un impatto molto maggiore in termini di risorse rispetto ai test unitari medi) e se verifica il codice effettivo o il framework sottostante.