2008-11-03 7 views
2

J'ai un objet OLE COM qui essaye d'écrire un wrapper, j'ai décidé de commencer à utiliser TDD pour écrire le code car je crois qu'il me donnera un meilleur sens de la direction avec ce que j'essaie d'écrire. L'objet COM a une interface comme ceci:Comment faire TDD avec un objet COM OLE

Interface Mapinfo 
    Sub [Do](ByVal cmd As String) 
    Function Eval(ByVal cmd As String) As String 
End Interface 

La commande [Do] prendrait somthing comme les suivantes

Mapinfo.Do("OpenTable("""C:\Temp\MyTable.TAB""")") 

Maintenant, je suis en train d'écrire un wrapper donc il y a une fonction comme ceci:

Mapinfo.OpenTable("C:\Temp\MyTable.TAB") 

maintenant, mon principal problème que je vais avoir, est que chaque fois que je veux écrire un nouveau test et un code que je dois créer une instance de l'objet OLE, attendez l'application pour commencer (30 secondes +), testez ma petite fonction, fermez et jetez l'objet OLE, changez le code et relancez le tout.

Ma question est: Y at-il une meilleure façon de faire tout cela sans devoir démarrer l'application OLE à chaque fois? J'ai entendu parler d'objets simulés mais je n'y ai pas vraiment beaucoup regardé, est-ce qu'ils pourraient m'aider ici? Si c'est le cas, comment?

EDIT: J'ai maintenant réalisé que je devrais créer un objet fantaisie pour Mapinfo, ma question est comment est-ce que je fais un objet de simulation qui peut prendre différentes chaînes formées? Comment cela va-t-il m'aider à vérifier que le code dans mon emballage est correct?

Répondre

3

Oui, les objets simulés aideraient. Essentiellement, vous créez un faux objet Mapinfo en se moquant de l'interface Mapinfo (vous devez renommer IMapInfo, btw).

Ensuite, vous indiquez à ce simulacre quels sont les appels à attendre et les résultats à renvoyer (le cas échéant). Vous pouvez également créer des tests où le fantôme lance des exceptions ou fait d'autres choses difficiles à invoquer en utilisant l'objet réel.

Les deux grands (et gratuits) .NET cadres de moquerie sont MoQ et Rhino Mocks. Rhino est plus mature et a plus de façons de configurer les simulacres. MoQ est le nouveau venu et a un ensemble de fonctionnalités plus petit et moins de façons de définir les attentes que Rhino.

Personnellement, je pense que MoQ est meilleur pour le nouveau venu à se moquer. C'est relativement facile à comprendre, toute la documentation disponible est pertinente pour la version actuelle (recherchez les tutoriels Rhino et vous obtenez des indésirables datant d'il y a des années qui ne s'appliquent plus), et cela fonctionne bien.

Questions connexes