• Choose a category
• All
• Classic-Fiction

{

public IList GetQuotes(String symbols)

{

var stocks = symbols.Split(',');

return stocks.Select(s => new StockInfo()

{

Change = "0%",

Company = s,

CurrentQuote = "1.1",

Date = DateTime.Today.ToString(),

Time = DateTime.Now.ToString()

}).ToList();

}

}

Finally, here’s the unit test:

[TestMethod]

public void TestIfQuotesAreBeingReturnedForEverySymbol()

{

// Arrange

const String testData = "XXX,YYY,ZZZ";

var inputSymbols = testData.Split(',').ToList();

var view = new FakeDefaultView(testData);

var presenter = new DefaultPresenter(view, new FakeQuoteService());

// Act

presenter.Refresh();

// Assert

Assert.AreEqual(view.Quotes.Count, inputSymbols.Count);

foreach(var quote in view.Quotes)

{

Assert.IsTrue(inputSymbols.Contains(quote.Company));

}

}

Ideally, a unit test is articulated in three main blocks: prepare the ground for executing the method under test, execute the method, and then check results against assertions.

Testing Presenters in Isolation

A relevant benefit that MVP provides is isolating the presenter code from the rest of the world. To be precise, MVP gives you guidance on how to isolate the presenter from the view, but it says nothing specific about the rest of the system. This means that keeping the presenter isolated from the middle tier is your responsibility.

When you test a method, you want to focus only on the code within that method. All that you want to know is whether that code provides the expected results in the tested scenarios. To get this, you need to get rid of all dependencies the method might have. If the method, say, invokes another class, you assume that the invoked class will always return correct results. In this way, you eliminate at the root the risk that the method fails under test because a failure occurred down the call stack. If you test method A and it fails, the reason has to be found exclusively in the source code of method A and not in any of its dependencies.

Achieving isolation is far easier if you apply dependency injection to the design of classes. For presenters, this means being injected with the view object and also any service layer component the presenter needs to work with. When this happens, testing methods on the presenter is really a piece of cake. (See Figure 15-12.)

Figure 15-12. Running unit tests.

Summary

For an ASP.NET application, you have two main options when it comes to choosing an application model. You can go with the traditional ASP.NET Web application model, which is based on the Page Controller pattern, or you can move toward ASP.NET MVC.

The traditional ASP.NET application model can be improved with a deeper separation of concerns by using a manual implementation of the MVP pattern. The MVP pattern isolates the view from the presenter and abstracts the view to an interface. In this way, the presenter can be coded against the view interface and becomes a reusable and testable piece of code. To finish with a flourish, you might also want to take out of the presenter any code that represents a dependency on the service layer. If you do, writing unit tests for the presenter becomes really easy and effective.

Even with these changes in place, however, ASP.NET Web Forms remains a hard-to-test framework. What if you need to deal with Cache or Session in your presenter? None of these objects will be available in the test project unless you spin the entire ASP.NET runtime. In other words, testing in isolation is very difficult. Options? Well, the best you can do is wrap access to Session, Cache, and other intrinsic ASP.NET objects in custom classes exposing a fixed interface. At the cost of an additional fairly thin layer, you gain the benefit of isolating presenters from ASP.NET runtime objects. And ASP.NET intrinsic objects are the subject of the next few chapters.

Part IV. Infrastructure of the Application

In this part:

Chapter 16

Chapter 17

Chapter 18

Chapter 19

Chapter 16. The HTTP Request Context

All great things are simple, and