I posted a comment to both News from the Forest and BSTR blog _place_holder;asking how others who were playing with Maverick.NET are doing Unit Testing. Justin and Ben both suggest having the Maverick controllers be lightweight wrappers around the real controller, which you can test.
I had considered this and knew it would work, but what I really wanted was a way to test the actual Maverick Controller using NUnit in a test-driven development environment.
So I spent a few hours today exploring the idea and ran into many roadblocks. The first thing I did was (attempt) to create a Mock Object replacement for Maverick.Flow.IControllerContext and System.Web.HttpContext. Using DotNetMock _place_holder;the IControllerContext Mock Object was a no-brainer, but, you can’t make one for HttpContext because it doesn’t derive from an interface and it is sealed.
But it doesn’t really do much itself. It actually just builds up and contains the Request and Response objects (as well as other stuff, but that isn’t really important to this discussion). It has two constructors, the one used by ASP.NET (I think) and one that takes an HttpWorkerRequest.
HttpWorkerRequest is an abstract class, so I thought I might have a chance here. I created a Mock Object (again using DotNetMock) that implemented the abstract members and fired it up. Didn’t work. Added some more members… still didn’t work. I was getting an exception inside of HttpRequest.get_Params(). Bummer. _place_holder;Did some browsing in Anakrino and haven’t really found the answer yet. At this point, I’m not sure if it is worth it. Unless someone else thinks it is worthwhile I’ll probably not take this any further.
So know I have to decide if I really want to use Maverick or if I will continue to expand my homegrown MVC technique (which by the way supports complete unit testing of the Controllers). We’ll see…