En un gran proyecto, hemos logrado aislar bastante bien el código de ArcObjects de nuestra lógica empresarial. En general, ese es el camino a seguir, diría, en lugar de intentar burlarse de todo, incluso si es posible usar marcos de burla para obtener algo del camino.
Pregúntese, ¿por qué siente la necesidad de burlarse? Por lo general, se debe a una abstracción que falta. Piense en pequeñas responsabilidades y minimice la superficie del enorme y feo monstruo ArcObject. Evite arrastrar los tipos de ArcObject solo porque se necesita algún aspecto de ellos en alguna parte.
Puedo dar un ejemplo concreto de nuestro proyecto. Una parte del código parecía depender de IMxDocument. Resultó que la única razón era que la vista activa necesitaba actualizarse. Así que creamos una interfaz IViewRefresher y solo trabajamos en eso; Fácil de burlarse y probar. Además, hace que la intención del código sea mucho más clara y elimina la tentación de que alguien comience a hacer cosas divertidas con el IMxDocument que no se suponía que hicieran porque todo lo que queríamos hacer aquí era actualizar. El mismo ejercicio se puede hacer con gran parte del código de ArcObjects.
Además, envolvimos todo el acceso a las clases de entidad en envoltorios seguros de tipo, nuevamente proporcionando un código simulado que protege el código comercial de ArcObjects.
Hemos discutido ni siquiera el uso de los tipos de geometría de ArcObjects, pero actualmente permitimos que esas interfaces se usen directamente en nuestro código. (Sin embargo, solo se permite el conocimiento de la interfaz y todas las instancias de geometrías utilizan nuestra propia fábrica de geometría).
En resumen, no estoy desanimando la burla, pero alentaría la burla a un nivel de abstracción diferente al de ArcObjects.