2012-12-28 5 views
7

Ogni volta che voglio esercitare un certo percorso di codice che altrimenti raggiungibile solo con un difficile da riprodurre condition come:Test di un difficile da raggiungere percorso di codice

if (condition) { code to be tested } 

ho or con un valore true:

if (true || condition) { code to be tested } 

C'è un approccio più elegante?

+0

Stai cercando di eseguire il codice tramite il debugger? Vorrei consigliare di esaminare il test delle unità. Una soluzione di simulazione potrebbe aiutare a rendere il tuo codice testabile.Scrivendolo come test unitario non solo puoi testare il tuo codice ora, ma puoi anche mantenere il test! –

risposta

13

penso che più elegant way sta usando the logical negation operator (!) come;

if (!condition) { code to be tested } 

Ma il modo più sicuro per il debugging o per testare scopi è possibile utilizzare un direttiva del preprocessore (come per il mio COMMET). Al termine il test è sufficiente rimuovere o modificare #define UnreachableTest

#define UnreachableTest //should be on the top of the class/page 

#if (UnreachableTest) 
    condition = !condition; //or 
    condition = true; 
#endif 

if (condition) { code to be tested } 
+0

Sì, mi sembra di più elegante. Con l'unica presa che non avrebbe funzionato quando la condizione è soddisfatta. Ma mi piace e credo che sarebbe buono nella maggior parte dei casi d'uso. –

+5

In tal caso, è possibile utilizzare una 'direttiva preprocessore' per modificare la condizione a scopo di test durante il debug. Come; '#define UnreachableTest' in cima ...' #if (UnreachableTest) condition =! condition # endif' Quindi il tuo codice effettivo da seguire. – Kaf

+5

Mi dispiace devo dare un -1 su questa risposta. Questo è un odore di codice molto brutto per cambiare la condizione logica per fare test. È pericoloso in quanto potrebbe portare a qualcuno che dimentica di rimuovere quel "!" e finiscono con il codice di produzione con la condizione capovolta e la creazione di errori/bug. –

13

La soluzione più elegante utilizza i mock. Prendere decisioni basate su dipendenze o parametri:

var mock = new Mock<IFoo>(); 
mock.Setup(foo => foo.IsBar).Returns(true); 
var sut = new Sut(mock.Object); 
sut.DoSomething(); 

E nel sistema in prova:

public void DoSomething() 
{ 
    if (_foo.IsBar) 
     // code path to test 
} 
+1

leggi la domanda prima di postare - 'vuoi esercitare un determinato percorso di codice che altrimenti verrebbe raggiunto solo in una condizione difficile da riprodurre 'L'obiettivo OP è testare il codice all'interno di' if', ovvero andare lì con 100% di probabilità – Nogard

+4

@Nogard Ho menzionato l'uso di mock. E aggiunto un esempio di codice. Leggi la risposta fino alla fine prima di commentare. –

+1

Certo che l'ho visto, ma la tua risposta pre-modificata (che ho commentato) ha dichiarato solo 'difficile da riprodurre la condizione' - anche il beffardo potrebbe usarlo. Quindi è stato aggiunto il campione Mock e si risolve il problema OP. – Nogard

2

darò per scontato questo non è uno scenario di test di unità dal momento che non è stato menzionato nella domanda. Di gran lunga il modo più semplice per eseguire test al volo di codice come questo è usando il comando Set Next Statement del debugger.

Impostare un punto di interruzione sull'istruzione if(), se necessario, oppure eseguire il codice finché non raggiunge tale istruzione. Quindi fare clic con il tasto destro del mouse sulla riga successiva, all'interno del corpo dell'istruzione if(), quindi selezionare "Imposta istruzione successiva". Il codice riprenderà l'esecuzione su quella riga, ignorando completamente if().

+0

Buono +1. Lo userò sicuramente. Ma nel caso specifico in cui voglio percorrere quel percorso almeno alcune volte è imbarazzante. –

3

Il tuo approccio, con "vero o", e l'approccio di if (! Condizione) sono i più semplici. Ecco un approccio che mi piace per i programmi di grandi dimensioni

Creare una funzione, chiamiamola testme (stringa const). E invece di inserire true in se test, si inserisce testme, con una stringa che identifica quel pezzo di codice.

if (testme("Location 123") || condition) { code to be tested } 

Poi, usando un qualche tipo di file di configurazione, o argomenti per il vostro programma (io preferisco config), si può assolutamente controllare quando TestMe ("Location 123") restituirà true. E puoi usare la stessa funzione in molte posizioni. Basta cambiare il file di configurazione per testare ciascuno di essi.

+0

+1. Ho usato una variabile booleana definita da qualche altra parte per quello scopo. –

2

Inserire il codice da testare in un metodo separato. Quindi puoi chiamare il metodo e ignorare il condizionale. Ora non dovrai preoccuparti di aggiungere "true" o, soprattutto, dimenticare di rimuoverlo.

È anche possibile aggiungere test unitari per il metodo in modo da poter modificare i parametri passati e testare tutti gli scenari desiderati.

Problemi correlati