2010-04-06 9 views
3

Existe-t-il un moyen facile de détecter si vous exécutez dans le contexte d'un test Visual Studio plutôt que de déboguer ou de publier? Voici le scénario: nous avons une classe de fabrique que nous utilisons abondamment dans notre base de code existante, et j'ai pensé au lieu de la refactoriser dans chaque classe afin de remplacer la fabrique par défaut par celle qui renvoyait les faux/faux objets. Je pourrais ajouter quelque chose dans la classe d'usine elle-même pour retourner ces objets fictifs si elle détecte qu'elle fonctionne en mode "test".Détecter si Visual Studio Test est en cours d'exécution

Répondre

4

Je ne pense pas que ce soit une bonne idée de mélanger le code de cas de test avec le code de domaine.

Je vous suggère de fournir une interface pour votre usine et d'implémenter des mocks pour cette interface à des fins de test.

Encore mieux, vous pouvez utiliser un cadre de simulation comme RhinoMocks.

+0

Ouais, c'est notre alternative. Nous venons d'obtenir notre base de code principale dans TDD et essayons d'éviter les maux de tête plus importants comme la modification de chaque classe de modèle, donc j'ai pensé que je demanderais. Nous prévoyons d'utiliser un cadre moqueur, ont joué avec NMock. – RTigger

1

Je suis d'accord avec l'évaluation de mcabral en se référant aux raisons (je pense que le refactoring vaut la peine), mais pour autant que la mécanique vont ...

Dans Visual Studio, vous pouvez définir un certain nombre de configurations autres que "Debug" et "Release", à la fois au niveau de la solution et du projet. Ainsi, vous pouvez créer une configuration "Testing", probablement basée sur la configuration de débogage. Ensuite, créez une configuration "Testing" dans le projet contenant la classe de fabrique.

Dans la fenêtre des propriétés du projet, sélectionnez l'onglet "Build". Sélectionnez la configuration "Testing" et définissez un symbole de compilation conditionnel: "TESTING".

maintenant dans votre code, vous pouvez utiliser

#if TESTING 
    // build stubs 
#else 
    // build real implementations 
#endif 
+0

Oui, ça marcherait. Je pensais quelque chose de plus proche de la façon dont vous pouvez appeler HttpContext.Current.IsDebuggingEnabled, mais pour tester. Je vais probablement aller sur la route refactor car nous devrons le faire finalement de toute façon. Merci pour la suggestion. – RTigger

+0

DI est parfaitement bien, mais il est bon de connaître des alternatives comme cette réponse. :) –

1

Avez-vous entendu parler de l'injection de dépendances ou du CIO? Cette situation est ce qu'ils sont pour. En tant que tel, je suggère d'utiliser un conteneur IOC pour fournir vos objets plutôt qu'une usine personnalisée. Si vous avez des exigences spéciales pour certains d'entre eux, vous pouvez mettre l'usine dans le conteneur IOC.

Vous pouvez ensuite configurer le conteneur différemment dans vos tests (ou ne pas l'utiliser du tout) et ce code restera hors de votre code principal.

1

Vous pouvez tester l'exécutable du processus en cours. Ce n'est pas très élégant, mais ça marche.

if (Process.GetCurrentProcess().ProcessName.ToLower().Contains("vstest.executionengine")) 
{ 
    // we are in a ms unit test 
} 
else 
{ 
    // normal programm execution 
}