C'è un modo per sapere quando viene chiamato il codice dall'esecuzione di un metodo di prova?come indicare nel codice se stiamo eseguendo da un test .net test .net
bool MyMethod()
{
if (/* are we running a test? */)
{
return true; // otherwise this will fail from the automated build script
}
else
{
// run the proper code
}
}
e vi prego di risparmiare i "questa è una pessima idea" commenti :)
si riconosce questo può essere una cattiva idea, ma potrebbe non essere a conoscenza delle alternative. Dovresti cercare in mocking frameworks - possono fornire un modo per iniettare implementazioni alternative nel tuo codice in fase di runtime nei test di unità. Questa è una pratica consolidata per consentire al codice di comportarsi diversamente nei test e nella produzione.
Sulla domanda principale.
Questo dipende dal framework di test dell'unità che si sta utilizzando. Non sono a conoscenza di una funzione specifica in NUnit (ad esempio) che segnala che ci si trova in un test. Altri framework (come MS Test) potrebbero benissimo fornire questo. Tuttavia, è facile da fare da soli.
Se stai legame con il codice sorgente, basta usare una direttiva #define per definire una variabile condizionale è possibile ramo su.
Se stai legandosi a una biblioteca, mi sento di raccomandare la creazione di una classe che si utilizza per tenere traccia se ci si trova in un test di unità o il codice vero e proprio, e impostare quella classe nella TestFixture setup method per indicare sei eseguire un test. Puoi anche usare Environment.SetEnvironmentVariable come metodo per evitare di scrivere una classe speciale.
Ok, vi risparmio la mia "questa è un'idea davvero male" commento.
Si può semplicemente dare al metodo un parametro bool isTestMode.
Cosa succede se il metodo viene chiamato attraverso una lunga catena di chiamate? Passare il parametro 'isTestMode' lungo tutta la catena di chiamate sembra molto intrusivo. È una brutta cosa spezzare l'incapsulamento su un singolo metodo: farlo su molti è molto, molto peggio. – LBushkin
@LBushkin: Sono assolutamente d'accordo, ma dal momento che il concetto di verificare se un metodo è invocato da un test è una cattiva idea, in primo luogo ho pensato che questo approccio avrebbe potuto portare l'OP a una rapida "correzione" nonostante tutto, concesso, è brutto. Ma lo è anche il controllo. La cosa giusta da fare è ciò che suggerisce @ Håvard S. –
Capisco. L'OP dovrebbe davvero considerare l'uso di una struttura di derisione se questa è una tecnica che deve essere utilizzata in più di una situazione estrema. – LBushkin
È necessario controllare l'attributo dei metodi di chiamata per riflessione! Non voglio dire che questa è un'idea letto, perché tu lo sai come la vedo io;)
L'approccio delineato nella tua domanda è una pessima idea.
Un approccio più pulito se si desidera che un metodo si comporti in modo diverso in fase di test rispetto a un altro, consiste nel rifattorizzare un'interfaccia con il metodo e iniettare un'implementazione diversa in fase di test.
Es .:
// Interface whose implementation changes under testing
public interface IChangesUnderTest
{
void DoesSomething();
}
// Inject this in production
public class ProductionCode : IChangesUnderTest
{
void DoesSomething() { /* Does stuff */ }
}
// Inject this under test
public class TestCode : IChangesUnderTest
{
void DoesSomething() { /* Does something else */ }
}
Ecco il mio suggerimento.
Invece di controllare il contesto, è sufficiente aggiungere nel codice bug condizionale:
#if DEBUG
/* assume you are running in a test environment here */
#endif
Questo è quasi non è male. E se non è esattamente quello di cui hai bisogno, puoi cercare in #define -ing "TEST" per quando potresti voler che il tuo codice di test non venga eseguito durante il debugging regolare.
questo dipende dal vostro quadro di test, si prega di elaborare. –
Questa è una pessima idea. Un'idea davvero pessima. Un'idea stupendamente pessima. – Will