• Choose a category
• All
• Classic-Fiction

When the complexity of the code rises above a certain threshold, the debugger alone is no longer sufficient for testing and needs to be backed by some good unit tests. You can write unit tests before you code (as TDD suggests) or after you’re done. It doesn’t really matter when you do it, as long as you come up with an exhaustive set of tests. TDD is considered an effective methodology to achieve just this result. Some small changes in the Visual Studio 2010 refactoring tools and the Test project template also make it worth a try for Web Forms developers.

Testing a Presenter Class

To test-run the increased testability of Web Forms with MVP let’s go through a test project aimed at ensuring an application correctly gets price quotes for a list of stock symbols.

Creating a Unit Test

Suppose you have the test project ready and you’ve added a unit test to it. A unit test is a class that looks like the one shown here:

[TestClass]

public class DefaultPresenterTests

{

[TestMethod]

public void TestIfQuotesAreBeingReturnedForEverySymbol()

{

}

}

Note

Choosing the right name for a test method is as important as writing good code. The test name must be representative of the scenario you’re testing and include a quick explanation of the scenario. A detailed guide from an expert in the field can be found here: http://www.osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.htm.

The test is expected to test the Refresh method of the presenter class we considered earlier. Figure 15-11 illustrates the first roadblock we encounter.

Figure 15-11. Attempting to create a unit test.

The idea is to get an instance of the presenter and invoke each method, passing some ad hoc input value (the aspect control) and observing results (the aspect visibility). As IntelliSense shows up in the figure, however, you need to provide some objects in order to instantiate the presenter.

The presenter has two dependencies—on the view and on the quote service. Your goal is to test the logic in the presenter class; you don’t want to test the view here and the service. These will possibly be the subject of other tests. On the other hand, you still need to provide a view and a service. Thankfully, you used a bit of dependency injection pattern in the design of the presenter class; therefore, you can now obtain a test double object and pass that in.

A test double is an object that looks like another one without providing the same behavior. A test double is typically coded in either of two ways—as a fake or a mock. A fake is an object with a hard-coded behavior and no state; a mock is an object with a dynamically defined behavior. You typically code the fake yourself as a custom class in the project and use ad hoc frameworks for mocks. Moq is one of these frameworks.

Important

Overall, there are four main types of test doubles: dummy objects, fakes, stubs, and mocks. A general consensus about what each test double object does exists for dummy objects and mocks only. A dummy object has no behavior and exists just to fill in a parameter list. A mock object is what I described above.

What about fakes and stubs, then? You might read subtly different definitions for each term and even find out that various authors use the term fake to indicate what another author classifies as a stub, and vice versa. My pragmatic approach is that it would be much simpler if we limit ourselves to two types of doubles: mocks and another, simpler, type of double you name the way you like. In this context, I prefer the term fake. As far as this chapter is concerned, feel free to replace fake with stub if that makes your reading easier in any way.

Here are some sample test doubles for the view and quote service:

public class FakeDefaultView : IDefaultView

{

private readonly String _symbols;

public FakeDefaultView(String fakeSymbols)

{

_symbols = fakeSymbols;

}

public IList Quotes { get; set; }

public String Message { get; set; }

public String Symbols

{

get { return _symbols; }

set {}

}

}

public