ASP.NET Web Forms MVP (Part III): Unit Test MVP

With the reading of Part I and Part II, you should have a basic understand of Web Forms MVP by now. In this post, let’s focus on how to write unit test to verify the presenter behaviour.

I’m using the following test frameworks: NUnit, Rhino.Mock, NBuilder. The syntax follows AAA.

The unit test class would looks like:

ASP.NET Web Forms MVP (Part II): MVP implemetation

On 11 July 2006, Martin Fowler decided to retire MVP, instead there’s two different design patterns: Supervising Controller and Passive View. In my point of view, they are different, but the difference is not much.

In this post, let’s focus how we implement ASP.NET Web Forms MVP. By the end of session, I believe you will have much more understand of MVP and start to feel the difference between the subdivision of MVP.

ASP.NET Web Forms MVP (Part I): Why do we need MVP?

In MS .NET world, there are a few popular techniques that web developers favour to implement web portals: ASP.NET Web Forms and ASP.NET MVC, either way has its pros and cons. And the selection of approach depends on the nature of the projects, which is more important: productivity or control? Hold on a second, there’s another sibling: ASP.NET Web Forms MVP. For convenience, I will refer classic ASP.NET as Web Form, ASP.NET MVC as MVC, ASP.NET web forms MVP as MVP.

People will question why there’s MVP. To keep the answer short,  let’s start from the statement from official MVP site:

The ASP.NET Web Forms MVP project is about bringing the love back to Web Forms through a renewed approach to using it – an approach that facilitates separation of concerns and testability whilst maintaining the rapid development that Web Forms was built to deliver.

LinqToSQL performance bottleneck: Select N + 1

Linq is a powerful popular language and is favoured by developers, as it shields the underlying data storage it queries against. In this post, I’d like to discover and discuss LinqToSQL basics, how Linq is translated into SQL statments and queried on SQL database. Further more, how to fine tune Linq query, to reduce the notorious performance bottleneck: Select N + 1.

Let’s start from basics first. In LinqToSQL, and other ORM framework, a common feature is to enable developer have granular control of the behavior of how and when Linq queries will be executed on data store. Eager loading and Lazy loading are two modes after a LinqToSQL data context is instantiated, and the mode cannot be change as long as the data context object lives (other framework, e.g. EF can change the mode at request, which is more flexible). I’ll briefly explain how each of the mode works in the following a few paragraphs.

What is eager loading? At the time when a Linq query is executed, LinqToSQL data context only executes the query on SQL DB and fetch the object that explicitly stated in the query, all child entity will not be loaded. If developer want to access the child entity, an famous object null reference exception will be thrown. The reason is obvious, eager loading only load the entity that is mentioned in the query selection. Although child entities are defined in the entity graph, data context will NOT fetch them as part of the query result. Here’s an example that demonstrates the idea:

Repository: Generic or specific?

Let’s start with the definition of Repository:

“A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations behind the scenes. Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer. Repository also supports the objective of achieving a clean separation and one-way dependency between the domain and data mapping layers.”

Repository, as an popular and useful design pattern, is applied to most of modern software architecture. In a multi-tier application: data access layer (DAL), business logic layer(BLL) and presentation layer(GUI) etc, repository usually resides in on its own layer, or can be co-exist with ORM framework (LinqToSQL, EF etc) to serve upper layer. Here’s a figure from MSDN, The Repository Pattern, it demonstrates the concept:

SSRS chart: display dual x-axis

For SSRS chart, at times it’s required to display the axis value on both side, for easy of use. Unfortunately, there’s no explicit feature come along with SSRS. I spent quite while to investigate and figured out have to display dual x-axis for Chart.

By default, when we create series for Chart, we can only get one x-axis rendered. See the image below

Test framework integration: NUnit, PartCover and ReportGenerator

Before we having look at how to integrate these three test frameworks, let’s have a look at their roles/responsibilities in the process.

NUnit: Executes unit tests. It’ll provide success or failure of the unit tests execution.

PartCover: Read the execution result of unit tests and produce code coverage information.

ReportGenerator: Render code coverage report from .xml file generated by PartCover.

Here’s the script (.bat) file to integrate these three apps together as one stop shop.

@ECHO OFF

"[YourPath]\PartCover.exe" --target=[YourPath]\nunit.exe --output=mytestresult.xml --include=[YourAssemblyName*]*

ECHO PartCover executed!

Pause

"[YourPath]\bin\ReportGenerator.exe" C:\mytestresult.xml C:\TestCodeCoverageResult

ECHO Report Generator executed!

Pause

start C:\TestCodeCoverageResult\index.htm

• When the first command is executed, a GUI from NUnit will display and you need to manually trigger the execution of all unit tests.
• Then close NUnit GUI.
• Then report generator will generate the code coverage as html page.

Here’s how the code coverage report looks like:

You can have a overview of the code coverage on different level, e.g. Assembly, class etc.

If you want more comprehensive information, click the class then you’ll be able to drill into the actual implementation code:

The lines of code indicated with green means it’s been covered in unit test.

The lines of code indicated with red means it’s not been covered in unit test.

How to integrate NUnit and NCover

NUnit is a unit testing framework, it can be executed on unit tests and tells developers whether the unit tests passed or not.

Does all unit tests passed mean the quality of code is insured? Not exactly.

An important figure indicating the quality of the code is CODE COVERAGE.

Now we’ll explore how to integrate NUnit with NCover to reveal the code coverage of the unit tests.

Integrate NUnit with Visual Studio 2008

For .NET developers, Visual Studio is the main IDE to work with. Properly laid unit tests will ensure the quality of the code and reduce the risk of regression bugs. There’re several frameworks that are the mainstream in the unit test world, e.g. NUnit, MSTest etc.

In this post, I’ll demonstrate how to integrate NUnit with Visual Studio 2008 to execute unit tests.

There’s three ways to debug unit tests based on NUnit:

ASP.NET Checkbox text alignment

When a checkbox is rendered in limited horizontal space, by default the new line will not have any indent. It’s just an akward look and feel.

To my suprise, it’s actually a well-known bug, please refer to here: http://connect.microsoft.com/VisualStudio/feedback/details/103259/asp-net-checkbox-control-label-should-wrap-to-the-side-of-not-under-the-checkbox

As workaround, I find out a easy way, the checkbox is rendered nicely in IE8/IE9/Firefox 8.0.1/Chrome.