UnityAutoMoq container is a great way to write maintainable Unit Tests. Since the container simplifies faking of dependencies, we can now focus on the actual test itself and spend less time on faking unwanted dependencies

For more info, please refer to the article below.

http://www.dotnetcurry.com/ShowArticle.aspx?ID=767

It works on Visual Studio 2010 and only works with C#.

You can download the Add-In from here.

Once you install this tool, you are ready to use the Regionerate.

You can also change the settings of Regionerate, go to Tools and click Regionerate Settings.

To use the Regionerate, simply use the Ctrl +R. You should see a window with few options as below. Alternatively just right click on Text Editor and select ‘Regionerate this’ from the context menu.

As per the above options, you can create regions based on the member types (I.e public, private, and internal), regionalise by the member name, regionalise by the member type and the member name, order the members without and regions, and remove existing regions etc..

Below is a code sample on selecting the ‘Primary Code Layout’.

I strongly encourage you to have a look at this Add-In as it is very useful.

Consider this generic method.

   1: public T Get<T>() { 

   2: //return null

   3: }

   4:  

If you want to return null from a C# generic method, which contains the Type(T) parameter, there are 2 options.

a. Restrict the type parameter T, to be class constraint

   1: public T Get<T>() where T : class;

   2: {

   3:    //return null

   4: }

   5:  

   1: public T Get<T>()

   2: {

   3:   return default(T);

   4: }

   5:  

Anything else will simply return their default values.  Here is summary on both reference and value types….

//If T is a reference type

var retVal = f.Get<String>(); //return null

……….

//If T is a value type – int

var retValInt = f.Get<int>(); //return 0

……….

//If T is a value type – char

var retValChar = f.Get<char>(); //return ”

……….

//If T is a value type – bool

var retValBool = f.Get<Boolean>(); //return false

……….

//If T is a value type – enum

var retValEnum = f.Get<EnumType>(); // For enum types, if there are no enum values specified, then the return value is 0. If there are values, then the first enumeration returns as the default.

……….

//If T is a value type – struct

var retValStruct = f.Get<Bar>(); //Structs, returns the value of the struct

……….

//If T is a Nullable<Int32>

var retNullableInt = f.Get<Int32?>(); //return null

……….

“If the code samples are harder to follow please visit my blog http://blog.rajsoftware.com/post/2011/06/07/Moq-4-and-e2809cLINQ-to-Mockse2809d.aspx“

While searching for Moq code samples, I came across that Moq 4 was released few months ago. The key improvement was the new “LINQ to Mocks”.

This post demonstrates few examples of the usage of Mocks and LINQ queries. For each example, we stub out dependencies using lambda expressions first, and then see the corresponding LINQ version. At the end we see the performance of each Unit Tests.

Note: I’m using the xUnit Testing Framework. However you can apply the same principles to other Unit testing frameworks.

Single Stub

Lambdas:

 1: [Fact]

 2: public void UpdateCustomer_WhenCustomerIsNotUpdated_ReturnsFalse()

 3: {

 4:     //Arrange

 5:     var dbServiceStub = new Mock<IDbService>();

 6:     dbServiceStub.Setup(d => d.Update(It.IsAny<Customer>())).Returns(false);

 7:     var customerService = new CustomerService();

 8:     customerService.DbService = dbServiceStub.Object;

 9:

 10:     //Act

 11:     bool isUpdated = customerService.Update(It.IsAny<Customer>());

 12:

 13:     //Assert

 14:     Assert.False(isUpdated);

 15: }

LINQ:

 1: [Fact]

 2:  public void UpdateCustomer_WhenCustomerIsNotUpdated_ReturnsFalse()

 3:  {

 4:      //Arrange

 5:      IDbService dbServiceStub = (from dbService in Mocks.Of<IDbService>() where dbService.Update(It.IsAny<Customer>()) == false

 6:                                  select dbService).First();

 7:      var customerService = new CustomerService { DbService = dbServiceStub };

 8:

 9:      //Act

 10:      bool isUpdated = customerService.Update(It.IsAny<Customer>());

 11:

 12:      //Assert

 13:      Assert.False(isUpdated);

 14:  }

Multiple Stubs

Lambdas:

 1: [Fact]

 2: public void UpdateCustomer_WhenCustomerIsUpdated_ReturnsTrue()

 3: {

 4:     //Arrange

 5:     var dbServiceStub = new Mock<IDbService>();

 6:     dbServiceStub.Setup(d => d.Update(It.IsAny<Customer>())).Returns(true);

 7:     var loggerServiceStub = new Mock<ILoggerService>();

 8:

 9:     var customerService = new CustomerService { DbService = dbServiceStub.Object, LogService = loggerServiceStub.Object };

 10:

 11:     //Act

 12:     bool isUpdated = customerService.Update(It.IsAny<Customer>());

 13:

 14:     //Assert

 15:     Assert.True(isUpdated);

 16: }

LINQ:

 1: [Fact]

 2: public void UpdateCustomer_WhenCustomerIsUpdated_ReturnsTrue()

 3: {

 4:     //Arrange

 5:     var fakes = (from dbService in Mocks.Of<IDbService>()

 6:                  from loggerService in Mocks.Of<ILoggerService>()

 7:                  where dbService.Update(It.IsAny<Customer>()) == true

 8:                  select new { dbServiceStub = dbService, loggerServiceStub = loggerService }).First();

 9:

 10:     var customerService = new CustomerService { DbService = fakes.dbServiceStub, LogService = fakes.loggerServiceStub };

 11:

 12:     //Act

 13:     bool isUpdated = customerService.Update(It.IsAny<Customer>());

 14:

 15:     //Assert

 16:     Assert.True(isUpdated);

 17: }

Mocks and Stubs

Lambdas:

 1: [Fact]

 2: public void UpdateCustomer_WhenCustomerIsUpdated_VerifyLoggerServiceLogIsCalled()

 3: {

 4:     //Arrange

 5:     var dbServiceStub = new Mock<IDbService>();

 6:     dbServiceStub.Setup(d => d.Update(It.IsAny<Customer>())).Returns(true);

 7:     var loggerServiceMock = new Mock<ILoggerService>(); //We verify against the Mock

 8:     loggerServiceMock.Setup(l => l.Log(It.IsAny<string>())).Verifiable();

 9:

 10:     var customerService = new CustomerService()

 11:     {

 12:         DbService = dbServiceStub.Object,

 13:         LogService = loggerServiceMock.Object

 14:     };

 15:

 16:     //Act

 17:     customerService.Update(It.IsAny<Customer>());

 18:

 19:     //Assert

 20:     Mock.Get(loggerServiceMock.Object).Verify(c => c.Log(It.IsAny<string>()));

 21: }

LINQ:

 1: [Fact]

 2: public void UpdateCustomer_WhenCustomerIsUpdated_VerifyLoggerServiceLogIsCalled()

 3: {

 4:     //Arrange

 5:     var fakes = (from dbService in Mocks.Of<IDbService>()

 6:                  from loggerService in Mocks.Of<ILoggerService>()

 7:                  where dbService.Update(It.IsAny<Customer>()) == true

 8:                  select new { dbServiceStub = dbService, loggerServiceMock = loggerService }).First();

 9:

 10:     var customerService = new CustomerService { DbService = fakes.dbServiceStub, LogService = fakes.loggerServiceMock };

 11:

 12:     //Act

 13:     bool isSend = customerService.Update(It.IsAny<Customer>());

 14:

 15:     //Assert

 16:     Mock.Get(fakes.loggerServiceMock).Verify(c => c.Log(It.IsAny<string>()));

 17: }

Testing an MVC Action Filter

Lambdas:

 1: [Fact]

 2: public void OnActionExecuted_WhenEmployeeSalaryIsEqualToZero_ EnsureActionExecutedContextResultEqualToFilterResult()

 3: {

 4:     //Arrange

 5:     decimal employeeUnpaidAmount = 0.0M;

 6:     var employeeServiceStub = new Mock<IEmployeeService>();

 7:     employeeServiceStub.Setup(s => s.GetSalary()).Returns(employeeUnpaidAmount);

 8:

 9:     var filter = new EmployeeSalaryNotificationAttribute

 10:     {

 11:         EmployeeService = employeeServiceStub.Object

 12:     };

 13:

 14:     var actionExecutedContextMock = new Mock<ActionExecutedContext>();

 15:     var routeData = new RouteData();

 16:     routeData.Values.Add("fakeIdKey", "fakeIdValue");

 17:     actionExecutedContextMock.SetupGet(r => r.RouteData).Returns(routeData);

 18:

 19:     var request = new Mock<HttpRequestBase>();

 20:     var httpContext = new Mock<HttpContextBase>();

 21:     httpContext.SetupGet(c => c.Request).Returns(request.Object);

 22:     actionExecutedContextMock.SetupGet(h => h.HttpContext).Returns(httpContext.Object);

 23:

 24:     //Act

 25:     filter.OnActionExecuted(actionExecutedContextMock.Object);

 26:

 27:     //Assert

 28:     Assert.Equal((actionExecutedContextMock.Object.Result as ContentResult).Content, filter.SalaryResult);

 29: }

LINQ:

 1: [Fact]

 2: public void OnActionExecuted_WhenEmployeeSalaryIsEqualToZero_EnsureActionExecutedContextResultEqualToFilterResult()

 3: {

 4:     //Arrange

 5:     RouteData routeData = new RouteData();

 6:     routeData.Values.Add("fakeIdKey", "fakeIdValue");

 7:

 8:     var fakes = (from employeeService in Mocks.Of<IEmployeeService>()

 9:                  from actionExecutedContext in Mocks.Of<ActionExecutedContext>()

 10:                  where employeeService.GetSalary() == 0.00M &&

 11:                  actionExecutedContext.HttpContext == Mock.Of<HttpContextBase>() &&

 12:                  actionExecutedContext.HttpContext.Request == Mock.Of<HttpRequestBase>() &&

 13:                  actionExecutedContext.RouteData == new RouteData()

 14:                  select new { EmployeeServiceStub = employeeService, ActionExecutedContextMock = actionExecutedContext })

 15:                  .First();

 16:

 17:     var filter = new EmployeeSalaryNotificationAttribute

 18:     {

 19:         EmployeeService = fakes.EmployeeServiceStub

 20:     };

 21:

 22:     //Act

 23:     filter.OnActionExecuted(fakes.ActionExecutedContextMock);

 24:

 25:     //Assert

 26:     Assert.Equal((fakes.ActionExecutedContextMock.Result as ContentResult).Content, filter.SalaryResult);

 27: }

Key things to notice:

- The tests with LINQ queries reflect the test scenarios/conditions in a more of a specification style. This improves the tests readability.

- The query returns an infinite number of mocks. Typically we access the first element.

   var fakes = (LINQ query).First();

- LINQ query result returns real object(s) and not the type Mock<T>. So we do not need to use the EmployeeServiceStub.Object. Instead we can just use the returned element.

   EmployeeService = fakes.EmployeeServiceStub;

- When you have multiple stubs or mocks, you can return all of them using an anonymous type.

   select new { dbServiceStub = dbService, loggerServiceStub = loggerService }));

- Not used in these code samples, but if you are using the MockFactory class, it is now absolute in v4. MockFactory will be retired in v5.

Performances:

Here is a very quick benchmark results on each Unit Test.

Unit Tests with LINQ queries take “tiny” bit longer than the Lambda counterparts. However, I would personally still use LINQ version as it improves the readability of Unit Tests.

There are different types of filters in MVC. Depending on the type of the Filter, and the scope of the Filter, the order of the execution also changes.

You may already aware that there are different types of filters within MVC framework. They are listed below.

1. Authorization filters

2. Action filters

3. Response/Result filters

4. Exception filters

The above list is ordered as exactly the order they executes within MVC framework. The Authorization filters always run first, and the Exception filters run at the end.

Specifying the Order property for Filters

Within each filter, you may specify the Order property. (All filters are derived from the abstract class FilterAttribute, and this class has an Order property). This property will ensure the filter runs in a specific Order. For an example, let’s say we have 2 Authorization filters, AuthorizationFilterA and AuthorizationFilterB and they are implemented as below.

 1: public class AuthorizationFilterA : AuthorizeAttribute

 2: {

 3:     public override void OnAuthorization(AuthorizationContext filterContext)

 4:     {

 5:         Debug.WriteLine("OnAuthorization : AuthorizationFilterA");

 6:     }

 7: }

 8:

 9:

 10: public class AuthorizationFilterB : AuthorizeAttribute

 11: {

 12:     public override void OnAuthorization(AuthorizationContext filterContext)

 13:     {

 14:         Debug.WriteLine("OnAuthorization : AuthorizationFilterB");

 15:     }

 16: }

Now, if I want these two filters to run in a specific order – AuthorizationFilterB to run first, and AuthorizationFilterA to run second, I can simply specify the execution order as below.

 1: [AuthorizationFilterA(Order=2)]

 2: [AuthorizationFilterB(Order=1)]

 3: public ActionResult Index()

 4: {

 5:     return View();

 6: }

When you run the code, the Output window should display that AuthorizationFilterB runs first, AuthorizationFilterA runs second.

OnAuthorization : AuthorizationFilterB

OnAuthorization : AuthorizationFilterA

Filter Scope

Within each filter type, you can define a scope. For an example, I could scope all my Authorization Filters to run within the Controller Scope, and all Action Filters to run in Global scope (Every Action within the MVC application).

FilterScope.Global is a new scope which was introduced in MVC 3. The existing scopes are First, Controller, Action, and Last. The complete enumeration is defined as below.

 1: namespace System.Web.Mvc {

 2:     public enum FilterScope {

 3:         First = 0,

 4:         Global = 10,

 5:         Controller = 20,

 6:         Action = 30,

 7:         Last = 100,

 8:     }

 9: }

By default, the filters with the lowest scope runs first. For an example, scope Global (10) executes first and scope Controller (20) executes second.

Filter Scope with explicit Ordering

Below example shows, how explicit filter ordering (using Order property) and scope of the filters determine their correct run order.

Let’s add the scope to our existing Authorization Filters – AuthorisationFilterA and AuthorisationFilterB. Please note that we haven’t changed the usage of Order property.

AuthorizationFilterA(Order 2) has the scope Global.

AuthorizationFilterB(Order 1) has the scope Action.

 1: public class AuthorizationFilterA : AuthorizeAttribute

 2: {

 3:     public override void OnAuthorization(AuthorizationContext filterContext)

 4:     {

 5:         Debug.WriteLine("OnAuthorization : AuthorizationFilterA (Order: 2) in scope : Global");

 6:     }

 7: }

 8:

 9: public class AuthorizationFilterB : AuthorizeAttribute

 10: {

 11:     public override void OnAuthorization(AuthorizationContext filterContext)

 12:     {

 13:         Debug.WriteLine("OnAuthorization : AuthorizationFilterB (Order: 1) in scope : Action");

 14:     }

 15: }

 16:

 17:

 18: [AuthorizationFilterB(Order = 1)]

 19: public ActionResult Index()

 20: {

 21:     return View();

 22: }

 23:

 24: GobalFilters.Filters.Add(new AuthorizationFilterA() { Order = 2});

According to the above Filter Scope enumeration, if we were to specify only the scope but not the Order property, then we would expect AuthorizationFilterA (in Global scope) to run first, and AuthorizationFilterB (in Action scope) to run second. Since we are explicitly specifying the Order property for both filters, AuthorizationFilterB (in Action scope – Order 1) runs first and AuthorizationFilterA (in Global scope – Order 2) runs second.

Output:

OnAuthorization : AuthorizationFilterB (Order: 1) in scope : Action

OnAuthorization : AuthorizationFilterA (Order: 2) in scope : Global

Now let’s add another Authorization filter (AuthorizationFilterC) to Global scope. Also note that we have not specified the Order property.

 1: public class AuthorizationFilterC : AuthorizeAttribute

 2:     {

 3:         public override void OnAuthorization(AuthorizationContext filterContext)

 4:         {

 5:             Debug.WriteLine("OnAuthorization : AuthorizationFilterC (no Order defined) in scope : Global");

 6:         }

 7:     }

 8:

 9: GlobalFilters.Filters.Add(new AuthorizationFilterC());

After running all three filters, you can see the output as below.

Output

OnAuthorization : AuthorizationFilterC (no Order defined) in scope : Global

OnAuthorization : AuthorizationFilterB (Order: 1) in scope : Action

OnAuthorization : AuthorizationFilterA (Order: 2) in scope : Global

For same Filter type, the filters without the explicit ordering (i.e AuthorizationFilterC) take precedence over the filters with explicit ordering (AuthorizationFilterB, AuthorizationFilterA).

Now let’s remove the Order property from both AuthorizationFilterB and AuthorizationFilterA

 1: [AuthorizationFilterB]

 2: public ActionResult Index()

 3: {

 4:     return View();

 5: }

 6:

 7: GlobalFilters.Filters.Add(new AuthorizationFilterA());

Output:

OnAuthorization : AuthorizationFilterA (no order defined) in scope : Global

OnAuthorization : AuthorizationFilterC (no order defined) in scope : Global

OnAuthorization : AuthorizationFilterB (no order defined) in scope : Action

As we would expect, the filters with scope Global (AuthorizationFilterA and AuthorizationFilterC) run first and second in order, the scope Action filter (AuthorizationFilterC) runs at the end. 2 Global filters (AuthorizationFilterA and AuthorizationFilterC) run order relies on the order which they were added to the Global Filter collection. In this example AuthorizationFilterA which was added prior to AuthorizationFilterC , runs first.

For the same filters, when determine the run order, first it sorts them by their order (lowest numbers first), and then by their scope (also lowest numbers first).

Controller as a Filter

In MVC the Controller itself is also a Filter. Controller implements all filters, so Controller can subscribe to all filter events.

 1: public abstract class Controller : ControllerBase,

 2: IActionFilter, IAuthorizationFilter, IDisposable,

 3: IExceptionFilter, IResultFilter

MVC framework ensures, the Controller always runs first, before any other filters get executed. It has been accomplished by specifying the scope as the First and the order property as Int32.MinValue. By default, an MVC filter has the value for the Order -1. Therefore Int32.MinValue along with the Scope First together ensures the Controller always runs first.

 1: public class ControllerInstanceFilterProvider : IFilterProvider {

 2:         public IEnumerable<Filter> GetFilters(ControllerContext controllerContext, ActionDescriptor actionDescriptor) {

 3:             if (controllerContext.Controller != null) {

 4:                 // Use FilterScope.First and Order of Int32.MinValue to ensure controller instance methods always run first

 5:                 yield return new Filter(controllerContext.Controller, FilterScope.First, Int32.MinValue);

 6:             }

 7:         }

 8:     }

Forward Filter Order and Reverse Filter Order

So far we have discussed the order of filters which get executed based on the explicit ordering (using Order property) and the scope which they can be belong to. However, MVC filters run order, do not only rely only by these two factors. Sometimes filters run in forward order and sometimes filters run in reverse order. Let’s see the below example.

Let’s say I have three Action filters (ActionFilter1, ActionFilter2, ActionFilter3), one Authorization filter (AuthorizationFilter) and two Exception filters (HandleErrorA, HandleErrorB). They are implemented as below.

 1: public class ActionFilter1 : ActionFilterAttribute

 2: {

 3:     public override void OnActionExecuting(ActionExecutingContext filterContext)

 4:     {

 5:         Debug.WriteLine("Forward Order - OnActionExecuting : ActionFilter1 (Scope Global)");

 6:     }

 7:

 8:     public override void OnActionExecuted(ActionExecutedContext filterContext)

 9:     {

 10:         Debug.WriteLine("Reverse Order - OnActionExecuted : ActionFilter1 (Scope Global)");

 11:     }

 12:

 13:     public override void OnResultExecuting(ResultExecutingContext filterContext)

 14:     {

 15:         Debug.WriteLine("Forward Order - OnResultExecuting : ActionFilter1 (Scope Global)");

 16:     }

 17:

 18:     public override void OnResultExecuted(ResultExecutedContext filterContext)

 19:     {

 20:         Debug.WriteLine("Reverse Order - OnResultExecuted : ActionFilter1 (Scope Global)");

 21:     }

 22: }

 23:

 24:

 25: public class ActionFilter2 : ActionFilterAttribute

 26: {

 27:     public override void OnActionExecuting(ActionExecutingContext filterContext)

 28:     {

 29:         Debug.WriteLine("Forward Order - OnActionExecuting : ActionFilter2 (Scope Controller)");

 30:     }

 31:

 32:     public override void OnActionExecuted(ActionExecutedContext filterContext)

 33:     {

 34:         Debug.WriteLine("Reverse Order - OnActionExecuted : ActionFilter2 (Scope Controller)");

 35:     }

 36:

 37:     public override void OnResultExecuting(ResultExecutingContext filterContext)

 38:     {

 39:         Debug.WriteLine("Forward Order - OnResultExecuting : ActionFilter2 (Scope Controller)");

 40:     }

 41:

 42:     public override void OnResultExecuted(ResultExecutedContext filterContext)

 43:     {

 44:         Debug.WriteLine("Reverse Order - OnResultExecuted : ActionFilter2 (Scope Controller)");

 45:     }

 46: }

 47:

 48: public class ActionFilter3 : ActionFilterAttribute

 49: {

 50:     public override void OnActionExecuting(ActionExecutingContext filterContext)

 51:     {

 52:         Debug.WriteLine("Forward Order - OnActionExecuting : ActionFilter3 (Scope Action)");

 53:     }

 54:

 55:     public override void OnActionExecuted(ActionExecutedContext filterContext)

 56:     {

 57:         Debug.WriteLine("Reverse Order - OnActionExecuted : ActionFilter3 (Scope Action)");

 58:     }

 59:

 60:     public override void OnResultExecuting(ResultExecutingContext filterContext)

 61:     {

 62:         Debug.WriteLine("Forward Order - OnResultExecuting : ActionFilter3 (Scope Action)");

 63:     }

 64:

 65:     public override void OnResultExecuted(ResultExecutedContext filterContext)

 66:     {

 67:         Debug.WriteLine("Reverse Order - OnResultExecuted : ActionFilter3 (Scope Action)");

 68:     }

 69: }

 70:

 71:

 72: public class AuthorizationFilter : AuthorizeAttribute

 73: {

 74:     public override void OnAuthorization(AuthorizationContext filterContext)

 75:     {

 76:         Debug.WriteLine("Forward Order - OnAuthorization : AuthorizationFilter (Scope Controller)");

 77:     }

 78: }

 79:

 80:

 81: public class HandleErrorA : HandleErrorAttribute

 82: {

 83:     public override void OnException(ExceptionContext filterContext)

 84:     {

 85:         Debug.WriteLine("Reverse Order - OnException : HandleErrorA (Scope Action)");

 86:     }

 87: }

 88:

 89: public class HandleErrorB : HandleErrorAttribute

 90: {

 91:     public override void OnException(ExceptionContext filterContext)

 92:     {

 93:         Debug.WriteLine("Reverse Order - OnException : HandleErrorB (Scope Action)");

 94:     }

 95: }

We will register the above filters as below…

ActionFilter1 has the scope Global, ActionFIlter2 has the scope Controller, ActionFIlter3 has the Scope Action, AuthorizationFilter has the scope Controller, HandleErrorA has the scope Global, and HandleErrorB has the scope Action.

At the beginning of this article I mentioned that the run order of different types of filters. First Authorization filters, then Action Filters, followed by Result filters and at the end the Exception filters. This is true, however within each type of filters, some executes in reverse order and some executes in forward order.

The best way to explain is to examine the generated output.

Forward Order – OnAuthorization : AuthorizationFilter (Scope Controller)

Forward Order – OnActionExecuting : ActionFilter1 (Scope Global)

Forward Order – OnActionExecuting : ActionFilter2 (Scope Controller)

Forward Order – OnActionExecuting : ActionFilter3 (Scope Action)

Home Controller, Index Action

Reverse Order – OnActionExecuted : ActionFilter3 (Scope Action)

Reverse Order – OnActionExecuted : ActionFilter2 (Scope Controller)

Reverse Order – OnActionExecuted : ActionFilter1 (Scope Global)

Forward Order – OnResultExecuting : ActionFilter1 (Scope Global)

Forward Order – OnResultExecuting : ActionFilter2 (Scope Controller)

Forward Order – OnResultExecuting : ActionFilter3 (Scope Action)

Reverse Order – OnResultExecuted : ActionFilter3 (Scope Action)

Reverse Order – OnResultExecuted : ActionFilter2 (Scope Controller)

Reverse Order – OnResultExecuted : ActionFilter1 (Scope Global)

Reverse Order – OnException : HandleErrorB (Scope Action)

Reverse Order – OnException : HandleErrorA (Scope Global)

• There is only one Authorization Filter in Controller scope and it runs first as expected.

• The Action Filters run at second. Notice that OnActionExecuting event runs in an order where the order of filter execution is determined by their scope (lowest number first in the enumeration). As you see, Action Filters OnActionExecuting event runs in a forward order.

• Home Controller’s Index Action executes.

• Action Filters do not always run in forward order. As you see during OnActionExecuted event, they run in a reverse order.

• Very similar to OnActionExecuted event, OnResultExecuted event runs in reverse order.

• Error Handler filters run at last. For each Error Handler filter, OnException event runs in  reverse order. Prior to MVC 3, ErrorHandler’s OnException event ran in forward order. This approach makes MVC exception filters more aligned with .NET exception handlers.

Summary

There are multiple factors involved when deciding the run order of MVC filters. This includes the explicit ordering, the scope they belong to, and the type of the filter. Controller itself is a filter and always run first. By design, MVC executes certain filters in specific order. Some are run in forward order and some are run in reverse order.

For your favourite posts, subscribe to my blog: http://blog.rajsoftware.com

http://blog.rajsoftware.com/post/2011/05/14/MVC3-Filter-Ordering.aspx

Working with Strings in C#.NET

VS2010 Undo Close Documents

Tooling support for Unit Tests and TDD (Test Driven Development)

Debugging, Visualizing and Querying data using LINQ

MVC2 Validation step by step

Useful Unit Testing Research Tools

Practical approach to Unit Testing

Regards,

Raj

As developers most of us write Unit Tests and we all know what is a Unit Test. Some may have slightly different opinions, but it is actually a programmatic verification of a single method/unit to ensure it behaves as expected. The reason I explain this because some developers still refers to a Unit is a component, assembly, or a module. When to comes to the term Unit Testing, you really testing a sensible testable unit of your software, and anything bigger than that would considered to be more of a integration testing. 

Benefits

Lets get real and discuss some of the benefits. I want to be more practical, and leave the MSDN Unit Testing benefits behind.

As a developer when you decide to write Unit Tests, do you ask the question from yourself, why I’m really writing these Unit Tests? Some of you answer Yes, and some of you say No.

Answer No, is simply because not knowing what you do, or because everyone else write Unit Tests. If your answer is Yes, that’s great, and you really consider the pros and cons of having Unit Tests.

All these benefits can be categorized into 3 main areas.

1.       Quality.

2.       Design.

3.       Cost benefits.

Lets talk about these areas briefly. 

The quality that provides by the Unit Tests can be many ways. It assists developing testable code. With TDD, the method/function that you write against a Unit Test, is well defined, and has a single responsibility. Unit Tests it self provide a valuable documentation to the project.  Less bugs will be introduced, also fixing bugs will be lot easier. As a developer you will have a great confidence on your system. 

If you practice TDD, you know Unit Test allows you to design a specific behaviour within your method. For example with TDD, you write your test first, make it fails, and then based on your test you write the method to ensure that your test passes. The result of this is basically designing a specific behaviour within your method. The other aspect of the Design is, when you design your system, you will also consider your functional requirements. Because one of the things that you need to ensure when you design your system is that your functional requirements have been met. Your Unit Tests are based on these functional requirements. I will discuss this in more detail in “Selective Unit Testing” section. 

We would love to develop a perfect system. But in reality, that is not always the case. Worse and the painful thing is some time projects are over the budget. This could be due to number of factors. One of the most common issues associated with the project cost is unexpected work at the end of the development cycle. This could be due to the number of bugs that have been raised during system testing. The number of iterations between the development and system testing cycles seems never ending due to the amount of bugs been raised. This can be due to poor system design, and or un-testable code. 

As you can see here, the number of defects you find is high during the development and the cost to fix those defects is relatively low when comparing to further stage of project life cycle. This is why the Unit Tests are important to ensure that we introduce fewer bugs during the development so the cost to fix those bugs are negligible at the later stage of the project cycle.

Selective Unit Testing

Writing “Unit Tests” is a good thing. Writing bad Unit Tests and/or unnecessary Unit Tests can lead to considerably high maintenance cost to your overall project. Do you believe on statements such as

“We should aim for 100% code coverage”, “Any Unit Test is better than none”, or “Our main priority is the Unit Testing”?. All these statements do not add much value at all. These are some examples of expressing the way of the excitement, which causes by the Unit Testing. 

Few years ago we hired a developer to one of our projects. He is very keen on Unit Testing and he spent lot of time writing and managing Unit Tests. At the end our project was over the budget, and not what we really expected. If he decided what is really important, and write only the necessary Unit Tests, it would have reduced our cost. 

This is where it is really important that we need to ensure we write the absolutely necessary Unit Tests. This is also applicable if you practice TDD. You just don’t need to write Unit Tests for every method you write with in your application. Lets see some of these characteristics, and then how you decide what Unit Tests to write. 

If you are aiming to write Unit Tests for every method to make your manager happy with higher code coverage, then it is fantastic to write these types of tests. But did you know that most of your tests did not add much value to the quality of your system at all. You see your entire tests pass with green ticks. There are so many green ticks make you feel good. Someone could argue that “All the tests are there to ensure that every method behave as expected when it runs”.  Well not necessarily correct. Did you consider if you have to make a change to a component how much re-factoring need to be carried out? 

Let’s explain this with an example. When you have an obvious method, which takes a String parameter and returns a Boolean, and there are 100 methods calling this simple method, change to this method to return a String would require changing all those 100 methods. How about the repetition? Your Unit Test probably written to ensure that calling method takes a String value and returns a Boolean. Isn’t this repeating the same thing? How about the DRY? The time you have spent to write this Unit Test, you should have spent for some important task such as analysing some business requirements. 

Consider the future maintenance cost for both production code and all these Unit Tests? The amount of time you need to write Unit Tests for every single method, the amount of time you have to spend to write tests for complicated methods, which add no obvious benefits to the design of the system. They do not add any value at all. 

You may also reluctant to make changes to your code because of the amount to Unit Tests and the fear of breaking them.

Decisions 

So how you decide what Unit Tests to write. In order to decide this, you need to understand the types of methods you would normally write within your application. 

1.       Simple methods – These methods are very obvious and simple. Just by having a look at code you can clearly see what it does.  The code it self explains the design of it.

        /// <summary>

        /// Gets the first name from fulllname.

        /// </summary>

        /// <param>The full name.</param>

        /// <returns>First Name</returns>

        public string GetFirstNameFromFulllname(string fullName)

        {

            if (string.IsNullOrEmpty(fullName))

            {

                return string.Empty;

            }

            return fullName.Substring(0, fullName.IndexOf(” “));

        }

If you perform additional design and verification through Unit Testing, this method will give you a minimal benefit.

So if the method is simple and the design is obvious, you don’t need a Unit Test. If you are a TDD partitioner, the concept is the same. You do not need to write tests for every method you write within your application. 

2.       Components that are already tested – I see some developers trying test components that have already been tested by the framework.            

        /// <summary>

        /// Adds the companies to cache.

        /// </summary>

        /// <param>The company list.</param>

        public void AddCompaniesToCache(IList<Company> companyList)

        {

            if (companyList != null && companyList.Count() > 0)

            {

HttpContext.Cache.Add(“companyCahchkey”, companyList, null, Cache.NoAbsoluteExpiration, new TimeSpan(0, 15, 0), CacheItemPriority.Normal, null);

            }

        } 

The real purpose of this method is to add a list of companies to cache. A test would be to ensure the list is added to the cache. Why would do you need to write Unit Tests against this method when the ASP.NET caching – Cache  is already tested for its capabilities. You can also see this method is very simple and hence Unit Tests are not required. 

3.       Complex methods and have no value to the design at all –

For example you may have a method that writes to a registry using a complex pattern, and then using a complex algorithm to generate some custom strings, then serializes the data before calling a web service.

It will be very exhaustive exercise to write dependencies for some of these complex methods. There are so many things and variations to consider. These methods are not related to your main design or requirements but to assist or help other methods to get the job done.  Most of these methods are self-contained algorithms. 

4.        High Level methods – There are methods within your application that integrated or calls other Units of methods. 

public void ManageResourceData(string resources)

        {

            if (string.IsNullOrEmpty(resources))

                throw new ArgumentNullException(“resources”);

            string retResourceValues = MergeResources(resources);

            SaveResourcesToAFile(resources);

            EmailReaources(resources);

            AddResourcesToDatabase(resources);

            SetUserPermission();

        } 

As you see here there are few units of methods being called. Writing Unit Tests for these types of methods, often waist of time. 

5.       Complex methods with so many dependencies.

Some refer to this as GOD methods. Most TDD practitioners not experience these type of methods as they would to like to perform one assert per single method. Also methods are smaller and always written for a single responsibility. You might come across with a situation where complex method with so many dependencies. The method itself performs so many other things and need to be re-factored in order to make it more testable. You can see these methods really hard to Unit Tests. You have two options

 a.       Re-factor your method and consider using interfaces, so you can mock all your dependencies during Unit Test.

b.       Simply do not waist your time to write the Unit Test. You may not have enough time to re-factor, and you can spend this time for something more useful.

So the next important question is “What types of methods that you write Unit Tests against?”. The answer is not simple, which why you need to think carefully, before you write Unit Tests.

 If you an application author, you would consider writing Unit Tests against the method that actually define your requirements. The focus should be to write methods with less number of dependencies by providing a single responsibility, while focusing on a specific requirement. Your dependencies should be easily mockable. The same consideration is applied if you are practicing TDD. When you implement your method with, then to pass your Unit Test, you should consider it as defining a specific requirement. If not, the test it self does not add value to your app.

The above graph displays the number of Unit Tests increases with the requirements. The more requirements you have the more Unit Tests you should have. 

For example you may have a high level requirement to write a Banking application where customer performs banking operations. When you design your application, you will consider more detail requirements, such as customers should be able to withdraw, deposit, transfer, print statements within your application. Regardless of wether you are TDD practitioner or not, you should consider writing Unit Tests for withdraw, deposit, transfer and print statements. By doing this you add the real quality to your application. You will have the confidence that your application performs as expected from the Unit Level.

You should not consider writing Unit Tests for any algorithms that may have to calculate your balances, encryptions, serializations, locked/isolated, or wether the database get initialised. These are some of the examples that you should avoid as they do not add much values your Unit Tests.

If you framework author you would consider writing Unit Tests ensure that the methods you have written confirms to the key design principles of your framework. Framework author should target the requirements, which provided by the design of the framework. For example, you are developing a resource management framework, and you need to ensure the developer who uses the framework could successfully retrieve images from your resource management system. So you would write a Unit Test to ensure that developers can retrieve images as expected.

I do not say that we should avoid Unit Tests and should not practice TDD. They both provide some real benefits to the application. However having unnecessary code / Uni Tests leads to more maintenance, and extra cost to projects. 

Server Side validation is based on System.ComponentModel.DataAnnotations, and Client Side validation is based on ASP.NET Ajax 4.0.

Both Server and Client Side validation are loosely coupled, and they are joined using JSON. 

You can also have multiple validator providers plugged in and run at the same time. You can remove the built-in validation providers and you can create your own once. 

Prior to MVC 2, MVC 1 used third party frameworks and plug-ins such as xVal to enable both client side and server validation. MVC 2 allows you to enable both server side and client side validation without having to use any third party frameworks or plug-ins. 

This article explains how to enable both server side and client side validation step by step.

 Enabling server side validation.

Lets start with the View Model. Please refer to the DemoModel code sample below.

There is a DisplayName attribute for each property. This attribute produces the name, which you should display within the View. Form validation point of view, it doesn’t add any value at all. What is important here is the “Required” attribute and “StringLength” attribute. These attributes belong to the System.ComponentModel.DataAnnotations namespace.

 There four built-in attributes that you can for validation. They are

• Required
• StringLength
• Range
• RegularExpression.

If any of above attributes doesn’t fit for your requirements, then you can easily create your own validation attribute if needed. For more info please refer to

http://haacked.com/archive/2009/11/19/aspnetmvc2-custom-validation.aspx

 public class DemoModel

    {

        [Required]

        [DisplayName("Product Code")]

        public string ProductCode { get; set; }

        [StringLength(10)]       

        [DisplayName("Product Description")]

        public string ProductDescription { get; set; }

        [Required]       

        [DisplayName("Product Date")]

        public string ProductDate { get; set; }

    }

1.       This is how the View looks like.

(Please not that greyed code samples are not relevant to MVC validation.) 

<%@ Page Title=”" MasterPageFile=”~/Views/Shared/Site.Master” Inherits=”System.Web.Mvc.ViewPage<ValidationDemo.Models.DemoModel>” %> 

<% using (Html.BeginForm()) { %>

        <div>

            <fieldset>

                <legend>Product Information</legend>

                <div>

                    <%= Html.LabelFor(m => m.ProductCode)%>

                </div>

                <div>

                    <%= Html.TextBoxFor(m => m.ProductCode) %>

                    <%= Html.ValidationMessageFor(m => m.ProductCode) %>

                </div>               

                <div>

                    <%= Html.LabelFor(m => m.ProductDescription) %>

                </div>

                <div>

                    <%= Html.TextBoxFor(m => m.ProductDescription) %>

                    <%= Html.ValidationMessageFor(m => m.ProductDescription) %>

                </div>

                <p>

                    <input type=”submit” value=”Submit” />

                </p>

            </fieldset>

        </div>

    <% } %>

 You can see that I’m deriving from ValidationDemo.Models.DemoModel. So my View will be strongly typed and I can bind to the Model properties using m => m.ProductCode etc.

The value that enter to the ProductCode text box is bound to the value of the Model using <%= Html.TextBoxFor(m => m.ProductCode) %>

 The validation message is displayed using the html helper extension.

<%= Html.ValidationMessageFor(m => m.ProductCode) %> 

If you remove this line, your validation will still work, however no messages will be displayed. 

Importantly you must ensure that your form which require validation is placed in between <% using (Html.BeginForm()) {  } tags. (See above)

2.       One last thing to remember is that you need an action method within your Controller to be able to execute your form POST. You must also pass the model to your action method, as a parameter. 

    public class ValidationController : Controller

    {

        public ActionResult Demo()

        {

            return View();

        }

        [HttpPost]

        public ActionResult Demo(DemoModel model)

        {

            return View();

        }    

    }

3.       Now when you click on Submit button, server side validation will trigger and the error messages are displayed.

4.    Using ValidationSummaryControl

       If you need the validation summary control (most of you do), you have to add the following helper extension method to the View. You can add this helper method anywhere you like (within the View). 

       <%= Html.ValidationSummary(false, “Product creation was unsuccessful. Please correct the errors and try again.”) %>   

 The first argument (excludePropertyErrors: true/false) specifies whether you want display list of error underneath the ValidationSummaryControl.

Enabling client side validation. 

MVC 2, uses Microsoft AJAX 4.0 as the default client side library. You can also use the JQuery version of the validation library. It is in MVC 2 Futures project. You can download it from MVC2 Future library.

1.       Ensure you reference three JS files within your application.

If you are using MS Ajax:

<script src=”/Scripts/MicrosoftAjax.js”></script>

<script src=”/Scripts/MicrosoftMvcAjax.js”></script>

<script src=”/Scripts/MicrosoftMvcValidation.js”></script>  

If you are using Jquery

<script src=”/Scripts/jquery-1.3.2.min.js”></script>

<script src=”/Scripts/jquery.validate.min.js”></script>

<script src=”/Scripts/MicrosoftMvcJQueryValidation.js”></script> 

Within your View, before the <% using (Html.BeginForm()) { %> statement, you need to add the code: <% Html.EnableClientValidation(); %> 

1. That’s it. Now run the app. You can see the client side validation in action.

If it is still not working, ensure the browser does not disable your JavaScript by default. For example in FireFox you need to ensure both Java and Javascript is not disabled. To be honest I don’t know why Java needed to be disabled. Please let me know if anyone finds out.

 Tweaks

Enabling Validation Summary Control for client side. 

Out of the box Validation Summary Control does not work for client side validation. For example you cannot display validation summary error massagers, within the Validation Summary Control during client side user interactions. To enable this you can implement a solution, which is described in the post here.

Those who new to LINQ to SQL, it is a database development model in the context of an Object Oriented Programming Model. LINQ is a broad topic. If you need to know more about LINQ, there lots of great articles in the web including some excellent sources from MSDN.   

.NET Framework 4.0 has also made significant enhancements to its LINQ model. This includes improvements to areas such as performances, query stabality, usability, LINQ to SQL class designer and much more. You can find some of those improvement in here. 

LINQ to SQL translates the queries you write into parameterized SQL queries (in text form) and send them to the SQL server for processing. Sometimes debugging LINQ queries can be problematic. If you want to know more about debugging LINQ queries please refer to this article.  

There are other ways to output LINQ to SQL queries so you can see the entire query that get executed. For example you can output to a debug window, file, or to a memory. Some examples are described in the below articles.   

LINQ to SQL log to debug window, file, memory or multiple writers  

View LINQ To SQL Statements Using A Debug TextWriter 

 VS2010 has a Historical Debugger  which can also be used to view and debug LINQ queries. More info is here. 

Debug Visualisers 

LINQ to SQL Debug Visualiser enables you to view and execute the LINQ queries on the fly. It was a part of beta releases of VS2008, but for some reason MS has dropped it from the RTM release. I cannot see this is integrated into VS2010 either. It is a separate download. You can download it from here. 

Take a look at this article on LINQ to SQL Debug Visualizer, which explains how it is integrated and used within Visual Studio.

VS LINQ to SQL Debug Visualizer has its own limitations to it. For example it does not diplay the complete query. It is hard to edit and execute while debugging. This article discribe some of the limitations.

There is another similar tool that you can download from VS Gallary. This tool should work with any database as well as MS SQL. You can find more information here. 

LINQPad 

I think this is an excellent tool to write and test your LINQ queries. It is a great tool to help you build any type of queries with LINQ. Standard edition is free and I recon every developer should have it. You save lot of time by having these tools which allows you to be more productive when writng queries. 

You can also connect to a SQL Server DB (Express or Compact Edition) and with a connection to your LINQ Data component (if you have built one) you can perform queries right against your data with LINQ – that’s excellent!  

The standard edition is free to download and it supports .NET 4.0 as well. Standard edition does not have the Autocompletion feature.  For more information on Autocompletion please click here. 

There is also great webcast that explains the new features of LINQPad with respect to the Entity framework. 

More importantly it is a great tool to learn and improve your skills on LINQ to SQL. 

You can download this tool from here.

I will try to keep this article as short as I can, and at the same time sounds interesting. There are so many developers out there. They all write code to develop/support applications. Some are good at it, some are average, and some are not good at it. It doesn’t really matter which category you are in, you always have room to improve yourself.

Here are some tips for you to become better.

1.       Practice make perfect. Write code whenever you can. The best way to learn newer technology is to use them, and work on them. Reading makes you knowledgeable but using them makes you even better.

2.       Work on open source libraries, read code and try to understand.

3.       Teach others, when they need, show them the right way.

4.       Learn from others as well. It is impossible to know everything, so you can always learn from others.

5.       Follow best practices when coding. This includes following best coding standards and writing readable code. Remember to review your own code before you commit.

6.       Why not make sure the quality code that you written are well maintained. Nowadays many developers write Unit Tests. So I see good developers write Unit Tests to ensure the quality of the code and the product it self.

7.       Developers make mistakes. Even the best developers make mistakes. So do not afraid to make mistakes, and do not afraid to try new things. We all learn from mistakes.

8.       It is always rewarding when you have good code written in an application. So always try your best.

9.       Once you written a piece of code, get someone to check. Do a code review. There is always room for improvement. You see things more with another pare of eyes.

10.   If you learn something new and share with fellow developers. It is a great thing that you share your knowledge.

 Happy programming.