I can understand not wanting to rewrite the UIP block to abstract
HttpContext. You could create your own facade for the UIP block though
and make calls against the facade. You would be able to test the UIP
facade because of the dependence on HttpContext, but this is a much
smaller footprint.

if you need to test static/non-virtual try TypeMock.Isolator. I
haven't used it, but it's suppose to work for these scenarios. Roy
Osherove has blogged about this in the past year quite a bit.

On Sep 4, 7:51 am, TheMightyKumquat <[email protected]> wrote:
> A lot of respondents missed the point of what I was trying to say,
> which was that with the tests I'm writing I'm not free to rewrite the
> code being tested. If I was, sure, I would be abstracting the ugliness
> away into some interfaces that are mockable. But unfortunately I
> didn't write the code I'm testing, and the tests I'm writing are an
> exercise 'after the fact' to prove that the code is OK and to create a
> body of unit tests for it. So I'm stuck with it not having any of its
> calls to HttpContext abstracted into mockable interfaces.
>
> Having said that, testing went very smoothly using HttpSimulator. The
> structure of the tests I wrote were basically (in VB.Net):
>
> using (new HttpSimulator("/", @"c:\inetpub\").SimulateRequest())
>
>   mocks = new MockRepository()
>
>   ' use Rhino Mocks to mock any objects in the test code that are
> possible
>
>   mocks.ReplayAll()
>
>   ' there may be calls to HttpContext in this method, but they'll work
> fine because the call's wrapped in the HttpSimulator using statement
>   testController.RunSomeMethod()
>
>   ' use assert statements to check the outcome of the code tested
>   Assert.IsTrue(<stuff that can be verified>)
>
>   ' Check that everything that had an expectation set up for it in
> Rhino Mocks has been called as per the expectation
>   mocks.VerifyAll()
>
> end using
>
> I had a couple of extra problems - even with the HttpSimulator
> working, a couple of things in HttpContext were null. From memory it
> was HttpContext.Current.Handler. I had to create a Page object and a
> Response object, assign the Response to the Page via Reflection (it's
> a readonly property) and assign the Page as the
> HttpContext.Current.Handler object to get past that small glitch. But
> overall, I'd highly recommend using HttpSimulator if you're stuck not
> being able to abstract away calls to HttpContext in the code you're
> testing.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Rhino.Mocks" 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/rhinomocks?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to