Permutation des paramètres avec typemock

Question

Je suis en train de coder quelques tests unitaires et je me demandais, est-ce dans le devoir de Typemock de remplacer les parémètres? Par exemple, j'ai une méthode qui repose sur un objet et dans le constructeur de cet objet, il y a des assemblages à analyser (un tableau de chaînes). Est-ce que je serais sur la bonne voie pour simuler la classe contenant la méthode, puis transmettre mes propres paramètres? Mais cela en soi a ses propres frais généraux. Ne serait-il pas préférable d'échanger les paramètres de la classe en cours de test? Est-ce possible? Enfin, il semble que je me soit rendu compte que si je veux tester facilement du code, j'ai plutôt des variables de type méthode que je veux mocker, elles devraient être des champs et donc accessibles de l'extérieur. Les variables d'ensemble de constructeur doivent être affectées à des références qui sont des champs. Seriez-vous d'accord avec cela? Je sais que c'est peut-être une question noobish mais je n'ai pas beaucoup utilisé de moqueries.

Merci

Answer 1

Si vous postez un exemple de code vous essayez de faire, je peux donner une meilleure réponse.
Fondamentalement, un vous voulez mocker les classes que vous voulez ignorer la plupart du temps, vous pouvez passer nulle ou une valeur par défaut aux méthodes truquées, car vous ne vous souciez pas vraiment de l'implémentation des types falsifiés.
Dans les cas arrière où vous voulez appeler les constructeurs et passer des arguments, vous pouvez une surcharge de
Isolate.Fake.Instance <>() qui accepte comme paramètres le comportement du constructeur par défaut et une liste d'arguments pour passer

var fake = Isolate.Fake.Instance<Foo>(Members.ReturnRecursiveFakes, ConstructorWillBe.Called, BaseConstructorWillBe.Ignored, "First Argument", "Second argument"); 

À propos de la deuxième question:
Les premiers champs ne doivent pas être accédés de l'extérieur, en fait il est plus difficile de truquer des champs. utiliser les propriétés à la place.
Deuxièmement, utilisez les champs/propriétés lorsque vous devez conserver l'état de la classe autre que celui qui utilise des variables locales.