Question

Je travaille sur un wrapper pour un objet COM qui ne peut que prendre et renvoyer des chaînes. L'interface de l'objet COM ressemble à ceci:

    interface IMapinfo
    {
        void Do(string cmd);
        string Eval(string cmd);
    }

Maintenant, j'ai créé des classes qui résument les fonctions de base comme suit:

    public class Table 
    {
        IMapinfo MI;
        public string Name
        {
            //pass the command to the COM object and get back the name.
            get{return MI.Eval("TableInfo(1,1")");}
        }

    }

Maintenant, j'aimerais effectuer des tests unitaires sur ces classes sans avoir à créer à chaque fois le véritable objet COM, à configurer le monde, puis à exécuter les tests. J'ai donc envisagé d'utiliser des objets fictifs, mais je suis un peu confus quant à la manière dont j'utiliserais les moqueries dans cette situation.

Je prévois d'utiliser Moq. J'ai donc écrit ce test comme suit:

        [Test]
        public void MockMapinfo()
        {
            Moq.Mock<Table> MockTable = new Moq.Mock<Table>();
            MockTable.ExpectGet(n => n.Name)
                .Returns("Water_Mains");

            Table table = MockTable.Object;
            var tablename = table.Name;

            Assert.AreEqual("Water_Mains", tablename,string.Format("tablename is {0}",tablename));
            Table d = new Table();
         }

Est-ce la bonne façon de se moquer de mon objet COM? Comment cette vérité que la chaîne envoyée à la fonction eval est correcte? ou est-ce que je fais tout faux?

Était-ce utile?

La solution

Est-ce un doublon? Comment procéder avec TDD avec un objet COM OLE

EDIT: On dirait que vous posez la même question, mais pour valider votre code moqueur (OOPS).

Vous n'êtes pas tout à fait là pour votre scénario moqueur. Vous avez raison de vouloir isoler les dépendances externes et votre objet COM répond à ce critère. Bien que je ne sois pas un gars de moq (je préfère RhinoMocks), l’idée derrière les simulacres est de tester les interactions ...

Le test d'interaction concerne la façon dont des ensembles d'objets cohérents fonctionnent ensemble. Un test valide dans ce scénario consisterait à écrire un test pour le composant dépendant du comportement de votre objet COM.

Dans ce cas, votre " Table " qui agit comme un wrapper pour votre objet COM, dépend également du comportement de cet objet. Par exemple, supposons que votre objet Table applique une logique personnalisée aux valeurs renvoyées par votre objet COM.

Vous pouvez maintenant écrire des tests isolés pour votre objet Table tout en simulant le comportement de votre objet COM à l'aide de Mocks.

public class Table
{
   public Table(IMapInfo map)
   {
      _map = map;
   }

   public string Name
   {
      get 
      {
        string value = _map.Eval("myexpression");
        if (String.IsNullOrEmpty(value))
        {
            value = "none";
        }
        return value;
      }
   }

   private IMapInfo _map;
}

[TestFixture]
public class TableFixture // is this a pun?
{
   [Test]
   public void CanHandleNullsFromCOM()
   {
       MockRepository mocks = new MockRepository(); // rhino mocks, btw
       IMapInfo map = mocks.CreateMock<IMapInfo>();

       using (mocks.Record())
       {
          Expect.Call(map.Eval("myexpression").Return(null);
       }

       using (mocks.PlayBack())
       {
          Table table = new Table(map);
          Assert.AreEqual("none", table.Name, "We didn't handle nulls correctly.");
       }

       mocks.verify();
   }
}

Peut-être que votre objet COM génère des exceptions à l'appel, ou peut-être qu'il ne gère pas très bien les expressions de chaîne. Nous testons en fait comment notre objet Table interagit avec IMapInfo sans être lié à l'implémentation de l'objet COM. Nous appliquons également une relation entre Table et IMapInfo dans le sens où l'objet IMapInfo doit être appelé pendant le test.

J'espère que cela vous aidera.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top