Personally I think that this is important, especially when I am dealing with legacy code that contains a lot of private members which I don't really care when I am unit testing my code. I think that private members should definitely be faked, and that should be high on the priority list.
Any thoughts?
To better define the discussion, this is about faking private fields, not any member (methods and properties are members too).
ReplyDeleteFaking private fields is generally a bad practice. However, your suggestion to assign recursive fakes to all private fields when creating a recursive fake has been thrown around the office and is on our backlog.
I am interested in hearing more opinions: do you think we should move this up in priority?
Doron,
ReplyDeleteOne reason developer choose TypeMock is that it helps faking legacy code that developers don't have control over. I'd say powerful mock framework should not give moral lessons, it should just help :-)
Another problem with not faking private methods is that it leave faked objects in inconsistent state. I've hit this problem once: depending on how the variable was accessed inside the class (using getter or directly), its values were different. I don't think it is acceptable. So I am all for faking private fields.
Doron correctly mentioned that the title is a bit misleading :)
ReplyDeleteJust to add up some statistics: I, for one, have never come across a task to fake a private member/field/etc. However, I think this needs to be implemented, at least for sake of consistency.
Not a priority for me :P
I've never had to fake private fields, but I can imagine a scenario where it might be handy. To get around some unfortunate ASP.NET behavior in .NET 1.1 one of our features had to set/get a private field in the base page class. In order to test that, we'd potentially need to mock it.
ReplyDeleteThat said, maybe the default behavior shouldn't be to mock private fields, but allow a parameter to be passed to enable that functionality.
Do you think that you can implement this using the new DoInstead or CThru?
ReplyDelete