We have, on a large project, managed quite well to isolate ArcObjects code from our business logic. That is generally the way to go, I'd say, rather than attempting to mock it all out, even if it is possible using mocking frameworks to get some of the way.
Ask yourself, Why it is you feel the need to mock. Typically, it is because of a missing abstraction. Think small responsibilities and minimize the surface of the huge, ugly ArcObject monster. Avoid dragging around ArcObject types just because some aspect of them is needed somewhere.
I can give one concrete example from our project. A portion of the code seemed to depend on IMxDocument. It turned out the only reason was that the active view needed to be refreshed. So we created an IViewRefresher interface instead and only worked on that; easy to mock and test. Additionally, it makes the intent of the code much clearer and removes the temptation for someone to start doing funny things with the IMxDocument that they weren't supposed to do because all we wanted to do here was refresh. The same exercise can be done with a lot of the ArcObjects code.
Also, we wrapped all access to feature classes in type safe wrappers, again providing mockable code shielding the business code from ArcObjects.
We've discussed not even using the geometry types of ArcObjects, but currently we do allow those interfaces to be used directly in our code. (However, interface knowledge only is allowed and all instantiations of geometries use our own geometry factory.)
In summary, I'm not disencouraging mocking but I'd encourage mocking at a different level of abstraction than ArcObjects.
This looks like a bug.
SG contains the ArcSDE geometry libraries and not the ArcObjects geometry libraries... it is used as a pre-filter before the test hits the ArcObjects geometry libraries.
Try this:
Omit this line:
pSpatialFilter.SearchOrder = esriSearchOrder.esriSearchOrderSpatial;
and since you are not saving a reference to the row, there is no need for you not to use recycling cursors, so switch the false flag to true.
pCursor = (ICursor)pFeatureClass.Search(pSpatialFilter, true);
You should see an improvement both in memory consumption and runtime speed. Nevertheless, if the bug is still hit, this will hopefully dramatically delay it :)
Best Answer
Adding this line fixes the issue