2009-12-11 17 views
4

J'ai un objet que les références un tas de valeurs Properties.Settings.Default... et j'ai besoin de stub ceux-ci dans le test unitaire pour cet objet.Comment puis-je remplacer l'objet Properties.Settings lorsque le test unitaire est dans un assemblage différent?

Malheureusement, le type de l'objet settings est déclaré internal et je ne peux donc pas y accéder à partir du projet de test unitaire.

Comment puis-je mapper les valeurs de retour pour ces propriétés? J'utilise Rhino Mocks pour me moquer.

Répondre

7

En général, je ne le ferais pas. Au lieu de vos objets "internes" en train de lire Properties.Settings.Default, demandez-leur de déclarer une propriété cconfigurable (soit au moment de la construction, soit via les propriétés), et de les remplir d'un autre morceau de code. De cette façon, vous pouvez tester tout sauf les lectures par défaut dans vos tests unitaires, et vous devenez moins couplé à une façon de lire les valeurs par défaut, ce qui facilite le changement de mécanisme dans le futur.

+1

oui, de cette façon, l'objet est plus réutilisable en ne dépendant pas des propriétés.settings – Benny

+1

Aussi "moins susceptible de casser". En recherchant les valeurs par défaut, l'objet a deux responsabilités: son travail actuel et savoir où trouver les paramètres. Ce serait une douleur sérieuse si vous avez 1000 classes tout en s'appuyant sur properties.settings, et décidez alors que vous voulez que ces données viennent d'ailleurs! – kyoryu

3

Une autre astuce que vous pouvez trouver utile pour contourner le problème interne, vous pouvez effectivement sélectivement rendre votre code interne visible à vos tests unitaires. Dans le code que vous testez, ouvrez votre AssemblyInfo.cs et ajouter quelque chose comme ce qui suit:

#if UNITTEST 
[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("YourUnitTestAssembly")] 
#endif 

Ensuite, vous devez juste le symbole UnitTest défini lors de la construction et votre assemblage de test sera en mesure de voir tous les membres internes .

0

Je sais que c'est une vieille question mais j'ai pensé que j'ajouterais dans ma solution comme son simple et pourrait aider quelqu'un.

La classe de paramètres créée est une classe partielle, nous pouvons en tirer parti pour créer notre propre implémentation de Default.

Créer un nouveau fichier dans le dossier Propriétés

internal partial class Settings : ISettings 
{ 
    private static ISettings _setInstance; 

    internal static ISettings Get 
    { 
     get 
     { 
      return _setInstance = _setInstance ?? Default; 
     } 
     set { _setInstance = value; } 
    } 
} 

Puis, quand on l'utilise ailleurs dans l'application, nous pouvons appeler Settings.Get .. Si vous souhaitez définir les valeurs de test, créez une classe qui hérite de ISettings et définit la nouvelle implémentation.

Si vos tests sont trouvés dans un projet séparé, vous devrez ajouter une autre classe pour exposer le setter à public. Nous ne pouvons pas changer le fichier de paramètres en public car cela serait simplement remplacé la prochaine fois que nous changerions ou ajouterions une valeur.