Overriding protected methods

[Jason G]

Hello everyone

I'm new to ActionScript/Flex, so this may be a dumb question, but I'd
love to use Mockolate to replace a protected getter on the target
class.

We're using PureMVC, and I'm writing a test against one of our
Proxies. I'd like to replace Notifier::facade() to return a mocked
IFacade. This way I don't have to do any complex setup, and I can
directly test the Proxy's onRegister() behavior.

The test code contains:
var cut : FriendProxy = partial(FriendProxy);
var mockFacade : IFacade = nice(IFacade);
mock(cut).getter("facade").returns(mockFacade);

But when the test is run, "facade" uses the original getter, not our
mock wrapper. Further playing around seems to show that only public
getters and methods can be overridden this way... Overriding a
protected getter is effectively a no-op.

Am I wrong, and there's a way to do this? Or is there a reason why we
can only tweak public methods?

I sure hope we can, since this would greatly help our ability to test
individual behaviors without having to poke "For Testing Only" holes
in everything or having to wire up more objects than a test truly
needs.

Thank you for your time!
Jason

[Drew Bourne]

Hi Jason, 

Proxying protected methods is not supported (yet). 

The current way of getting the reflection information required to generate the proxy classes does not include protected or private method or properties. As such the proxy class generator cannot override those with the intercepting logic. 

I have work-in-progress generator for proxies that can intercept protected methods and properties. It uses bytecode reflection which has its own set of issues I have yet to resolve. 

cheers, 

Drew

[Jason G]

Hi Drew

Excellent! Glad to hear it's on the horizon. ;)

[Ryan Hanks]

Hi,

What's the status of this? I couldn't seem to find an issue related to this at github.

Thanks.

[Drew Bourne]

Hi Ryan, 

It's dependent upon work in as3-commons-bytecode which Roland and I are working through slowly. 

Are you testing flex framework code, another library or your own classes? I'd recommend different workarounds depending on context. 

cheers, 

Drew

[Ryan Hanks]

Hey Drew,

Thanks for the reply.

We're testing our own classes. We're dealing with a system that's largely untested from a fine-grained unit test perspective, and we have a lot of god objects. Being able to stub protected methods seems like an easy way to configure tests for changes and additions these classes without having to worry about all of the behavior a given action may perform.