Question: Maybe this is counterproductive, I don't know, but right now I am in need of a debugger in IntelliJ that are aware of EasyMock mocks and especially what the mocks methods actually returns.

For example, I have a transport interface `ITransport`, which has some methods that had to be mocked, and where I only want some of methods returning something. E.g.

```
ITransport myTransport = createMock(ITransport.class);

```

I want myTransport.getID() to return a mocked ID 10.

```
expect(myTransport.getID()).andReturn(10);

```

With ID 10 I want a method to be invoked once,

```
expect(myTransport.publish(any(...)));

expectLastCall.once();

```

Something in the transport class breaks and `myTransport` isn't called, and my test fails. Know I just want to step through the code with the debugger to check why my test fails. So I add a breakpoint to verify the values of the mocked `myTransport` object. But they all say "null", even the ID. So I assume, with some brief investigation, that the cause of this is the EasyMock mock class, it doesn't really update the object with value (which sounds reasonable) and instead returns the mocked value at runtime when the method is called.

So, are there any mock aware debuggers for IntelliJ that lets me see which value the method will eventually return.

Yes, and before I receive responses saying that "The debugger is not required if you write unit tests for everything", I just want to state that I know about that. And this is legacy code, or at least code that wasn't written with testing in mind.

Answer: 
This may not be what you're looking for... but it feels like the problem is more on the debugging approach.

A mock object is really just that - a mock - meaning it's a fake empty object that doesn't do anything unless you specifically tell it. When your debugger inspects the mock object, it won't find any values that you did not specifically program it to return. It's not meant to hold values.

EasyMock has an argument capture feature, but since you just want it for debugging, this is probably the wrong approach. Mockito has a spying feature that could be suitable for what you want, but it would involve additional mock-programming statements.

I would say the easiest approach would be to implement your own `ITransport` just for use in your test class. That way you can implement `getID()` to always return `10` and put in an assert statement inside your `publish()`. And you can implement whatever other methods you need in order to capture additional data for debugging purposes. And you get to keep this test-only `ITransport` for either shared use or future debugging needs.
Indeed, the methods are mocked but the internal implementation of the class is left to itself. 

Usually, you don't need to know what is returned since you're the one who recorded it in the first place.

You can also evaluate myTransport.getID() in your debugger. But doing this will consume the expectations.

However, it seems like a good idea to be able to list the all current pending expectations on a mock. And maybe to have a peek function. You can request such features on the EasyMock bug tracker: <http://jira.codehaus.org/browse/EASYMOCK>