14.3. Solution

We will start by creating a new test fixture called PayControllerTests as well as create a controller called PayController. Our callback action will not be rendering a view; it will simply accept the posted data from the payment processor (in this case, PayPal), perform the handshake, and process the data. Our first test will make sure that we are not returning any views:

[Test]
public void callback_should_return_null()
{
    var con = new PayController();
    var result = con.Callback();
    Assert.IsNull(result);
}

This test will fail until we add the following code to our PayController:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Callback()
{
    return null;
}

For the next test, we want to verify that the callback method performs the handshake:

[Test]
public void callback_should_perform_hand_shake()
{
    var mockService = new Mock<IPaymentService>();
    mockService
        .Expect(s => s.PerformHandShake(MyMocks.Request.Object));

    var con = new PayController(mockService.Object);
    con.SetFakeControllerContext();
con.Callback();

    mockService.VerifyAll();
}

The test mocks the payment service and sets an expectation that the PerformHandShake must be called using the Request object of the controller. We will reuse the mocks and helper methods we already created in our project and then set the fake context on the controller to use them.

This test causes a cascade of code changes. First, we want to be able to compile the code and need to add an overloaded constructor to accept an instance of ...

Get ASP.NET MVC 1.0 Test Driven Development: Problem - Design - Solution now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.