Sur un grand projet, nous avons assez bien réussi à isoler le code ArcObjects de notre logique métier. C'est généralement la voie à suivre, je dirais, plutôt que d'essayer de tout simuler, même s'il est possible d'utiliser des cadres de simulation pour obtenir une partie du chemin.
Demandez-vous pourquoi vous ressentez le besoin de vous moquer. Généralement, c'est à cause d'une abstraction manquante. Pensez à de petites responsabilités et minimisez la surface de l'énorme et laid monstre ArcObject. Évitez de faire glisser les types ArcObject simplement parce que certains de leurs aspects sont nécessaires quelque part.
Je peux donner un exemple concret de notre projet. Une partie du code semblait dépendre d'IMxDocument. Il s'est avéré que la seule raison était que la vue active devait être rafraîchie. Nous avons donc créé une interface IViewRefresher à la place et n'avons travaillé que sur cela; facile à se moquer et à tester. De plus, cela rend l' intention du code beaucoup plus claire et supprime la tentation pour quelqu'un de commencer à faire des choses drôles avec l'IMxDocument qu'ils n'étaient pas censés faire parce que tout ce que nous voulions faire ici était actualiser. Le même exercice peut être effectué avec une grande partie du code ArcObjects.
De plus, nous avons encapsulé tous les accès aux classes d'entités dans des encapsuleurs de type sécurisé, fournissant à nouveau du code factice protégeant le code métier d'ArcObjects.
Nous avons discuté de ne même pas utiliser les types de géométrie d'ArcObjects, mais actuellement nous autorisons ces interfaces à être utilisées directement dans notre code. (Cependant, seule la connaissance de l'interface est autorisée et toutes les instanciations de géométries utilisent notre propre usine de géométrie.)
En résumé, je ne décourage pas la moquerie, mais j'encouragerais la moquerie à un niveau d'abstraction différent d'ArcObjects.