Browsing all articles in Debugging

Debugging Communication Errors

Typemock,Debugging communication Error

I couldn’t sleep all night, thinking that on the last company meeting, when one of my employees complained that he can’t finish his tasks because of personal issues that he has with other employees,  I basically told him and the rest of the team to help each other and be a team, I was managing them instead of empowering them, and knew that the issue probably remains unresolved…

For the next meeting, I decided that no matter what I do, I will make sure that my team goes back to work after they resolved their issues themselves, empowered to continue working and achieving  their goals.

I started the meeting by asking each of them to bring up a personal issue that he has with another employee and to resolve it with the other on the spot. It was amazingly interesting to see how they raised the problems, and found the solution at the same time.

One of the employees complained that he requested help via email. He sent the email, but didn’t receive any answers. He needed certain people in the company to fill out part of a form, but none of them did. Nothing but a simple communication problem; they all got the email but didn’t understand the call for action. His way to resolve the matter was to sit with each one of the people involved personally and to fill the form together, that way he will make sure that they understand their share, and he will make sure that it’s done on time.

One of the developers complained about having troubles with managing his time.  I explained that this is not an interpersonal problem, and asked him questions which led him to realize that his lack of time is because he is always helping people. He can’t say no to anyone, and he doesn’t want to look bad or disappoint anyone, so he ends up making everybody happy by helping them, but having no time to do his own tasks. When he understood, it was a major breakthrough, and he realized that he will have to start saying no to people or at least to say I’m busy now I will help you later; I would love to follow and see if he would really do it…

It’s only two examples out of many. The amazing and inspiring part was to see how each one of them was empowered and found his own way to resolve his problem without being told or managed.

Last, out of the entire company there was one developer that claimed that he has no personal issues with anyone in the company. When I asked him if others has problems with him, he was confident that their answer would be no.

On the second round that we did, each one of the developers needed to share their successful interpersonal communications, almost everyone mentioned him.  I guess that it was as obvious to them as it was to him.

One of the more gratifying surprises from the exercise was hearing about the successful communication routes that have developed that I did not know about.  For example, two developers found the time and were sensitive enough to help a third that was in major distress.  They simply encouraged him, but it was exactly what he needed in order to get back on track.   Another developer thanked the sales team for providing him with relevant historical customer support information.  Yet another thanked a team member in marketing for helping him with the wording in an important email to customers.

By the end of the process, it was clear that the team understood the power of effective communication and they now had better tools to resolve interpersonal issues with team members independently.  And at Typemock we know – your result (read: code) is always better when you’re working with the right tools.

When you know immediately when something is wrong, you are able to fix it, and get an immediate indication that your code is correct without the involvement of the QA. In other words, exactly like the Manager that empowered his team to resolve their problems without his involvement and without managing them, the unit testing helping the developers’ resolve problems on the spot and avoid QA involvement.


Nicer Tracing with [VerifyMocks]

An unknown feature, (at least till this blog) of the final version of TypeMock 4.0 is the Tracer Utility. Up till this version each time you called MockManager.Init() or when TypeMock started a new sessions the Tracer showed an Initialization (#number) to make it possible to trace the mocked calls.

The reason for this was that we just didn’t know that names of the tests. But when using the [VerifyMocks] attributes, we already know the names of the tests and we incorporated this into the Tracer. So using the decorators will make it easier to trace your mocks


Notice the names of tests actually appear in the tracer. Cool!


How to Debug with TypeMock.NET without losing your head

TypeMock.NET has many internal features that allow debugging code that has some mocked methods, and although this works most of the time, there are some things you need to watch out for. All these have to do with the Visual Studio’s Property Evaluation or funceval (see Mike Stall’sFunc-eval is evil post)

Basically whenever you see in a Property value in a watch or local variable window, the debugger hijacks a thread and evaluates the property.

Now, this works fine if your properties don’t change the state of your code, once they do, this will mess up your code.

The following code:

private int count; public int Count { get { return count++; } }

can really confuse, as while stepping with the debugger count will be increased. The same is true for TypeMock.NET expectations, as long as we are not using RepeatAlways() we are changing the state of our code.

So if we have the following expectation.


using (RecordExpectations recorder = RecorderManager.StartRecording()) { recorder.ExpectAndReturn(SomeProperty, 10); }

and we break just before we call SomeProperty, and evaluate it, we will see that SomeProperty returns 10, but when we continue it won’t return that value any more and the test will fail. Very annoying.

What is worse is trying to step through the recording session. If you break while inside a recording (in the using block), TypeMock will catch all the evaluations and mock them. Using the Tracer while doing this stunt will show how the expectations are being filled…

See how NUnit.Core is being mocked :twisted:
and the get_MyProperty is also mocked because of funceval calls.


Until the debugger comes with a better API here are things to remember.

  1. Don’t break while recording – There is really no reason to break there as no calls are actually made.
  2. If possible mock Properties with RepeatAlways() to make sure that debugging won’t confuse.
  3. This is not always possible as you might sometimes want to validate that a property was called only once, in this case just keep in mind that the debugger can change your programs’ flow
  4. Turn off evaluating Properties:
  • Visual Studio 2003,  go to Tools -> Options -> Debugging -> General and uncheck Allow property evaluation in variables windows
  • Visual Studio 2005, go to Tools -> Options -> Debugging -> General and uncheck Enable property evaluation and other implicit function calls