http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Haack has an interesting post on this topic: http://haacked.com/archive/2007/12/09/writing-unit-tests-for-controller-actions.aspx He recommends the Test Specific Subclass if you have protected methods. I think he implies in his post that most protected virtual methods will become public to assist TDD - which would ideally solve this problem. http://ayende.com/3044/dont-like-visibility-levels-change-that#comment9http://ayende.com/3044/dont-like-visibility-levels-change-that#comment9Thu, 27 Dec 2007 12:00:26 GMTJust curious, would you recommend this mechanism over something like "Subclass and override"? For example: public class TestController : Controller { public new virtual void RenderView(string action) { base.RenderView(action); } } Slightly more annoying, but with compile-time safety. http://ayende.com/3044/dont-like-visibility-levels-change-that#comment8http://ayende.com/3044/dont-like-visibility-levels-change-that#comment8Thu, 13 Dec 2007 14:49:11 GMTCertainly, But you won't get the compile time access to that, RhinoMocks works at run time. http://ayende.com/3044/dont-like-visibility-levels-change-that#comment7http://ayende.com/3044/dont-like-visibility-levels-change-that#comment7Thu, 13 Dec 2007 14:04:45 GMTI'm a little into John's approach but with a twist. Wouldn't it be possible to have Rhino mock expose all protected methods as public on creation of a partial mock http://ayende.com/3044/dont-like-visibility-levels-change-that#comment6http://ayende.com/3044/dont-like-visibility-levels-change-that#comment6Thu, 13 Dec 2007 14:02:36 GMTJohn, I am accepting patches :-) http://ayende.com/3044/dont-like-visibility-levels-change-that#comment5http://ayende.com/3044/dont-like-visibility-levels-change-that#comment5Thu, 13 Dec 2007 13:31:16 GMTThis may sound like blasphemy, but why doesn't Rhino mocks just add the ability to reference a method by name instead of having to call the method when registering it in the framework in order to handle non-public members. I love the way it works for public methods, but if I need to add an extension method and then use reflection to wire up my mock I may as well be using the framework instead since I'll have the weakly typed issues anyway. I would just feel dirty using extension methods in this way. Plus it seems like extra unnecessary steps every time you need to do something like this. http://ayende.com/3044/dont-like-visibility-levels-change-that#comment4http://ayende.com/3044/dont-like-visibility-levels-change-that#comment4Thu, 13 Dec 2007 13:23:15 GMTCould someone hint the guys at Microsoft that their code "protection" through internal/private/protected members all over the place might just not be such a good idea in the light of extensibility? http://ayende.com/3044/dont-like-visibility-levels-change-that#comment3http://ayende.com/3044/dont-like-visibility-levels-change-that#comment3Thu, 13 Dec 2007 10:45:07 GMTJust one slight change is needed to the code. The RenderView extension method has to look like this since the original method is protected. But is is still a very neat technique. Seems like MVC is drawing out a lot of the cool stuff you can do with extension methods: public static void RenderView(this Controller self, string action) { typeof(Controller).GetMethod("RenderView", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic, null, new Type[] { typeof(String) }, null ).Invoke(self, new object[] { action }); } http://ayende.com/3044/dont-like-visibility-levels-change-that#comment2http://ayende.com/3044/dont-like-visibility-levels-change-that#comment2Thu, 13 Dec 2007 10:39:38 GMTNice! I need to update my post with this technique. http://ayende.com/3044/dont-like-visibility-levels-change-that#comment1http://ayende.com/3044/dont-like-visibility-levels-change-that#comment1Thu, 13 Dec 2007 09:29:32 GMT