Debugging Mocked Methods
Although strict XP practices, value tests more then debugging, there are many cases where you still have to debug the code base to find defects. Doing this with mocked objects can be very fishy.
Evaluating Mocked Properties
When evaluating methods and Properties in the Debugger, the Debugger Hi-Jacks the running application to run the code that evaluate the values. A mocking framework doesn’t know that you are running in the debugger and will return the mocked value. This might cause the test to fail, because of unexpected calls or different return values.
Breaking While Recording
When in Natural Mocks recording block, breaking inside the block will lead to very strange results. This is because the Hi-Jacked threads that are evaluating Properties are being recorded and mocked. The current workaround is to turn off automatic property evaluation.
Debugging Mocked Methods
When stepping into a mocked method, or putting a break point on it, you will never reach the break point. This is because the method is mocked and is never actually run. This is very confusing and I have heard some developers spending a lot of time trying to understand what is happening.
Preview
These issues have been a major feature of our coming TypeMock version and will all be solved.
- Mocked Property and Method Evaluation will not change the test!
- Breaking in the Recording Block will nor mess up the recording!
- There is a visual cue that will allow you to see that the method is mocked.
Example of debugging a mocked method.
As you can see, it is very easy to see that the method is mocked and understand why you cannot step into the method.
What do you think of the visual cue?
We are thinking about adding more information to the editor
- Return Values
- Conditional Returns (based on arguments)
- Different instances
What other information would you like to know while debugging?
Bookmark at:
Subscribe!
RSS 2.0
13 Responses to “Debugging Mocked Methods”
1 Travis Illig 27 December 2007 @ 5:46 pm
I like the visual cue, but make sure it doesn’t interfere with other add-ins that provide visual enhancements like the DevExpress CodeRush and Refactor products.
It would be nice if you could do something in the Watch windows to let the person know that the value they’re looking at is mocked. Like putting a [mocked] next to the variable name or something.
2 Omer Mor 27 December 2007 @ 6:09 pm
I’m sorry - but what exactly is the visual cue? I can’t notice anything unusual in the image.
3 Eli Lopian 27 December 2007 @ 6:21 pm
Thanks for the tip Travis,
The watch window is something that will add, but probably not in the coming release.
4 Omer Mor 27 December 2007 @ 6:28 pm
Eli,
Can you please tell where in the picture exactly is the visual cue?
5 Eli Lopian 27 December 2007 @ 6:29 pm
Omer,
The mocked method DoSomething() has a purple surrounding box.
What cue would you like to see?
6 Omer Mor 27 December 2007 @ 8:55 pm
Oh, ok…
I mistaken it with a ReSharper feature.
My ReSharper is configured to outline blocks in a similar fashion when the cursor is placed outside the block’s brackets. It looks exactly the same.
7 Eli Lopian 27 December 2007 @ 8:58 pm
Hmm,
So what kind of cue would you suggest?
8 Omer Mor 27 December 2007 @ 9:37 pm
I’ve no idea. I’m no so sure your cue is bad - I just mistaken it for a ReSharper feature which looks the same.
But that feature is only visible when the cursor is near the brackets, and your cue is visible as long as you’re inside a mocked method, so I guess it shouldn’t be confusing.
9 glb 15 January 2008 @ 5:42 pm
Resharper put a visual cue in the left column (where the red debug spot appears)to (for instance) indicate that a method implements an interface. Why don’t you do something like that? Maybe have an ‘M’ in a circle to left of the method name.
10 Rob Cannon 15 January 2008 @ 7:00 pm
I also (at first) didn’t see anything different from what I usually see with Resharper.
11 John Dhom 23 January 2008 @ 11:54 pm
Yeah, the outlining is similar to my R#r settings as well. Using the gutter is reasonable (per glb’s comment).
/jhd
12 Eli Lopian 23 January 2008 @ 11:57 pm
Thanks for your feedback. I will try to get this into the application
13 Eli Lopian’s Blog (TypeMock) » Blog Archive » Typemock Isolator - Beta - Better Community 7 February 2008 @ 1:56 am
[…] Roy and Paulo have already talked about some new features.Mainly Better Debugger Integration and Mocking Fields!!! […]
Leave a Reply