remember; you are testing the controller to ensure *that* the redirect action took place. not *how* the redirect took place. what you want to test is that the Response was told to redirect to an area/controller/ action. how the response constructs the url should not be part of the controller test. think of it this way, if you where using a mock object for Response instead of MR's StubResponse. you would be testing the controller called Response.Redirect(controller, action), not how the Response handles the call. StubResponse has the RedirectedTo property to test the controller called redirect. it just happens to use castle as the default extension.
On Dec 20, 9:32 am, Patrick Steele <[email protected]> wrote: > Thanks John -- that did the trick! Although I'm wondering why you > wouldn't pass along the existing UrlInfo data to the new one. Like > this > > protected override IMockResponse BuildResponse(UrlInfo info) > { > return new StubResponse(Cookies, new UrlInfo(info.Area, > info.Controller, > info.Action, info.AppVirtualDir, ".html")); > > } > > Both ways work -- your override as well as the modified one above. > I'll have to dig in and see how the UrlInfo is used to see why it > doesn't matter. > > --- > Patrick Steelehttp://weblogs.asp.net/psteele > > On Sat, Dec 19, 2009 at 5:42 PM, John Simons <[email protected]> > wrote: > > I assume you are using BaseControllerTest to test your controllers, > > right? > > > The problem is that the BaseControllerTest when creates an instance of > > the StubResponse is calling the ctor that has ".castle" hardcoded! > > To get around this you need to override this method on your > > BaseControllerTest derived class: > > protected virtual IMockResponse BuildResponse(UrlInfo > > info) > > { > > return new StubResponse(cookies, info); > > } > > and replace with: > > protected override IMockResponse BuildResponse(UrlInfo > > info) > > { > > return new StubResponse(Cookies, new UrlInfo("", > > "controller", > > "action", "/", ".html")); > > } > > > I haven't tested this!, but it seems to be the only logical place that > > ".castle" is hardcoded, so hopefully this workaround will do the > > trick. > > If it doesn't let me know and I'll dig further. > > > Cheers > > John > > > On Dec 20, 5:24 am, Patrick Steele <[email protected]> wrote: > >> I noticed that too, but didn't dig in to figure out why -- I just used > >> the ".castle" in my assertions. I know that when we tweak web.config, > >> remember we're configuring how IIS will process the request. Since > >> we're not running under IIS during a unit test, we won't get those > >> settings. I think ".castle" is the default and the web.config > >> settings allow you to change it. > > >> --- > >> Patrick Steelehttp://weblogs.asp.net/psteele > > >> On Fri, Dec 18, 2009 at 4:53 PM, JakeS <[email protected]> wrote: > >> > I'm starting this new project with the best of intentions-- unit > >> > testing my controllers. So far it's all working out pretty well > >> > except when I test for my redirects. I've got my site set up so it > >> > interprets .html files, instead of having URLs ending in .rails > >> > or .castle. But in the unit tests, when I check Response.RedirectedTo > >> > it shows "/Controller/Action.castle". > > >> > Where does it get the extension for this? Is there somewhere I can > >> > set it for my unit tests? -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
