Extreme Programming: Short Cycles

cyclesIn our world of digital technologies, things move fast and so do the needs of our customers. Thus, as professional software developers, we have to adapt our way of working on a project, being responsive to change is key.

For this kind of development environment, some project management models are no longer up to the task, like the Waterfall of the V-Model for example. To follow the Agile Software Development Manifesto, Extreme Programming (X.P.) is based on short development cycles.

By doing so, the development teams are able to produce new features for their products at a regular interval. The short cycles of X.P. are all about feedbacks, with them you can focus on the tasks/improvements that will provide the most value for your customers and for your company.

X.P. defines two “high-level” cycles for the development process, the iteration plan and the release plan.

The Iteration plan

An iteration is a period of time (1 to 3 weeks) during which the development team work on a set of user stories defined during an iteration planning.

The features to work on during an iteration are picked by the business analysts depending on the budget the team has. In this case the budget represent the amount of work the team can achieve for the given period.

When the next iteration is defined, the feature to produce should not change nor the priority of them. This way the developers can cut the user stories into different tasks and focus on them.

The Release plan

The user stories completed by the development teams have to be released in order to improve the products and to add value. This is defined during a release plan.

A release contains the work of several iterations, the user stories are chosen during the release planning and as the iteration planning the amount of work to achieve should not exceed the budget the teams have. The order of implementation of the user stories is defined for the release at this moment.

Once a release plan is defined the first iteration of it can be planned as well. The content of a release can change, some user stories might be cancelled, others might be introduced or the priority for some might change. Yet this should not have impact on the current iteration.

Extreme Programming like others “agile” methodologies is focused on delivering value at regular interval. To do so it requires short development cycles to allow feedbacks to happen regularly by releasing new features quickly. This is achieved by defining a release plan and several iteration plans in it.

See you next time!

Extreme Programming: User Stories

user-storyAs professional developers, our role is to write high quality code within our applications. Yet this is worthless if it does not provide any value to our customers.

There are not much companies that will hire you to let you work on whatever you want. These businesses have customers that need new features and improvements in the software they buy and use.

It most cases you will work in an industry you know nothing, or almost nothing about. But don’t worry, you will work with people who know it, the business analysts. They know how to provide value for their customers and they need talents to implement it: YOU! You form a whole team.

In order to ease the specification and especially the prioritization of development in an “agile” environment, you can rely on user stories.

User Story

A user story describes a single requirement for the system. It is expressed by the business team and it generally written as a sentence matching the following format:

As a <role>, I want <goal/desire> so that <benefit>

The details are not defined within the sentence because they are likely to change with time even if the main goal will not. Details are discussed during conversations between the business analysts and the development team.

The use of user stories allow the developers to be able to provide a low risk estimate and by extension a budget for the feature. It is focused on the user needs, specific technology details should be excluded (data base schema, algorithm, …).

The role

In the sentence describing a user story a role is defined. By doing so you are able to detect the user of the system. It is likely the person who will know all the details you need to complete the task.

If the user story needs a new User Interface (U.I.) and this person is the final user of it, you should ask him how he wants to use it. Because I think that a UI providing the goal of the user story but with a really bad User Experience (U.X.) is not as valuable as it should be.

The goal

In a user story the goal is the new feature that needs to be created. It defines what the final customer/user wants and needs. This is the part of the system that needs to be well crafted, from a code perspective and from a user experience perspective (see previous section).

The benefit

The last part of the user story describes the benefit. This way you can understand the value it provides to the customers/clients. It can also describes the final result and if you know it, you can test it!

If the benefit of a user story is hard to write down maybe it means that it is not as valuable as you think it is. And therefore there might be others user stories to prioritize first.

In an agile environment such as Extreme Programming (X.P.) the use of user stories allow the business analysts to express their needs for the customers without writing an entire documentation containing every details. They are focused on the user, the goal and the benefit. This way the development team should be able to properly estimate it and they gather the details using a good communication in the whole team.

See you next time!


Image credits:

https://boagworld.com/usability/user-stories/

Extreme Programming: Whole Team

whole-teamExtreme Programming (XP) is one of the agile software development methodologies. Therefore it focuses on short development cycles and to do so it has defined several practices to follow when working with it. In this blog post I will introduce the first one: Whole Team.

As a professional developer I firmly believe in collaboration among a software development team. I believe that is by working together that we are able to create more valuable products.

The developers, the testers, the project manager and the business analysts (sometimes called “product owners”) have a common goal: product value for their customers. This is why they have to work closely with each others and they should be able to speak with each others easily, a good communication is mandatory.

Every role is important in the organization and everyone as a part to play in the project. The business analysts know what has to be done, they represent the customers needs. The developers know how it has to be done, the testers ensure that the quality standards are met and the project manager makes sure that everything runs smoothly.

I know that all of this makes sense, yet sometimes I feel like the common vision is lost in a software development team. Maybe you have experienced the well-known “programmers vs the business” work environment, or maybe the “developers vs testers”.

I know that I have experienced similar situations and I was part responsible for it. Because I only had consideration for my world, where coding is king and everything else is secondary. Now I keep in mind the “big picture”: creating value for the clients. It still requires writing well-crafted code, it is my role in the team. I have to make my teammates understand my point of view and I also have to understand their.

When working in an agile environment, in Extreme Programming for instance, you have to keep in mind that you are part of a whole team. Everyone as a role toward the creation of value.

See you next time!


Image credits:

http://www.branddrivendigital.com/how-to-engage-your-whole-team/

The Law of Demeter

demeterDo not let the title mislead you, today’s article is not about greek mythology. As always I will speak about software development. In my last article I introduced the Tell Don’t Ask principle where it was about object behavior using encapsulation. The Law of Demeter (LoD) is an Object Oriented Programming (OOP) design guideline that fits well with this last principle. This practice uses encapsulation in order to reduce coupling between your components, and therefore it helps you improve your code quality. Here is a definition for the LoD:

Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.

For OOP it can be described with the followings list, which I consider easier to digest:

A method of an object may only call methods of:

  1. The object itself.
  2. An argument of the method.
  3. Any object created within the method.
  4. Any direct properties/fields of the object.

I will now demonstrate the use of the LoD with an example in C#. I will use the famous “The Paperboy and the Wallet” case from the original paper about the Demeter practice. In this example, the paperboy get a payment from a customer who as a wallet.

Initial situation

public class Wallet
{
    public float Value { get; set; }
 
    public void AddMoney(float amount)
    {
        Value += amount;
    }
 
    public void SubMoney(float amount)
    {
        Value -= amount;
    }
}
 
public class Customer
{
    public string FirstName { get; set; }
 
    public string LastName { get; set; }
 
    public Wallet Wallet { get; set; }
}
 
public class Paperboy
{
    public void SellPaper(Customer customer)
    {
        var payment = 2.0f;
        var wallet = customer.Wallet;
        if (wallet.Value >= payment)
        {
            wallet.SubMoney(payment);
        }
        else
        {
            // come back later
        }
    }
}

The Wallet class just stores its amount and exposes two methods to manipulate this amount. A customer has a first name, last name and a wallet. And finally the paperboy sell its good to a given customer using its wallet.

The problems

To me, it does not really looks like a real world scenario, I personally don’t give my wallet to every person I must pay. The paperboy knows that the customer has a wallet and he is able to manipulate it, this can be seen as a Single Responsibility Principle violation. And nothing prevents the paperboy code to do something like this:

customer.Wallet = null;

And maybe the customer’s wallet is already null, and therefore the paperboy’s method has to add a null check to avoid unwanted NullReferenceException.

public void SellPaper(Customer customer)
{
    var payment = 2.0f;
    var wallet = customer.Wallet;
    if (wallet != null)
    {
        if (wallet.Value >= payment)
        {
            wallet.SubMoney(payment);
        }
        else
        {
            // come back later
        }
    }
}

For a simple functionality, I think my code starts to look “heavier” than it should. A modification of the Wallet class will result in an update in the Paperboy class as well, the 3 classes are tightly coupled and it is unnecessary. The paperboy just wants to be paid, no matter if the money comes from a wallet or something else.

Following the Law of Demeter

I will now rewrite the code to fix the previous issues. To do so I will use encapsulation and add a PayAmount() method to the Customer class.

public class Wallet
{
    public Wallet(float initialAmount)
    {
        Value = initialAmount;
    }
 
    public float Value { get; private set; }
 
    public void AddMoney(float amount)
    {
        Value += amount;
    }
 
    public void SubMoney(float amount)
    {
        Value -= amount;
    }
}
 
public class Customer
{
    public Customer()
    {
        FirstName = "John";
        LastName = "Doe";
        _wallet = new Wallet(20.0f); // amount set to 20 for example
    }
 
    public string FirstName { get; private set; }
 
    public string LastName { get; private set; }
 
    private Wallet _wallet;
 
    public float PayAmount(float amountToPay)
    {
        if (_wallet.Value >= amountToPay)
        {
            _wallet.SubMoney(amountToPay);
            return amountToPay;
        }
        return 0;
    }
}
 
public class Paperboy
{
    public void SellPaper(Customer customer)
    {
        var payment = 2.0f;
        var amountPaid = customer.PayAmount(payment);
        if (amountPaid != payment)
        {
            // come back later
        }
    }
}

Now, the paperboy can only access to the first name and last name of the customer, without being able to modify them (for invoicing purposes for example). And he can tell the later to pay a certain amount for the paper without knowing that the money comes from a wallet, the LoD is also known as the principle of least knowledge. The relationship between the Paperboy class and the Wallet class has been removed, the code is less coupled.

With my refactoring, I increased the readability and the maintainability of my code without losing any functionality.

More than simple dot counting

Sometimes the Law of Demeter is stated with a simple phrase: “use only one dot“. This aims to focus on avoiding lines like the following, from the initial example:

customer.Wallet.Value;
customer.Wallet.SubMoney();

The risk with doing this is that you can have a NullReferenceException if the Wallet instance is not initialized, in these examples I used 2 dots. And here it is an indication that the LoD is violated.

But this is not always the case and this is why I consider that the rule should not be sum up to the simple “only one dot” principle. When working with the .NET framework and especially with Linq, it is easier to chain the calls and it has been designed to be used that way. I don’t consider that the following code sample breaks the LoD even if I use more than one dot.

enumerable.Where(o => o.LastName == "Doe").Select(o => o.FirstName).ToList();

The LoD is about loose coupling and encapsulation, it is not about dot counting.

This is the end of my presentation of the Law of Demeter, which I use a lot to avoid unnecessary coupling in my code. Remember that when working with an OOP language you are able to control the way you design your components to expose only what is required and nothing more.

See you next time!


Image credits:

http://sterendenn.deviantart.com/art/Art-Nouveau-Demeter-255076200

Dependency Injection and highly coupled objects

power-plugI consider that Dependency Injection (DI) is a very helpful pattern, I love to use it in order to reduce the coupling in my code and it helps me when writing unit tests. But sometimes the code depends on objects that are difficult or impossible to mock.

The HttpContext class of the ASP .NET MVC framework is one example of this kind of object.

I created the following Controller and View as examples:

public class IndexController : Controller
{
    [HttpGet]
    public ActionResult Index()
    {
        string[] languages = HttpContext.Request.UserLanguages;
        return View(model:languages);
    }
}
@model string[]
@{
    Layout = null;
}
 
<!--DOCTYPE html>
 
<html>
<head>
    <meta name="viewport" content="width=device-width" />
    <title>Index</title>
</head>
<body>
    <div> 
        @foreach (string language in Model)
        {
            @language
            <br/>
        }
    </div>
</body>
</html>

This view displays the languages preferences from the request for the visitor:

languages-preferences

Now, I want to test my Controller (even if there is no logic in my example) with the following code:

[TestClass]
public class IndexControllerTest
{
    [TestMethod]
    public void IndexActionTest()
    {
        IndexController controller = new IndexController();
        ViewResult view = controller.Index() as ViewResult;
        Assert.IsNotNull(view);
    }
}

I just want to check that the view is not null but the test fails. I get a NullReferenceException because the HttpContext property of the Controller is null. This happens because there is no web context when executing the test and it makes sense since the execution occurred in a test context.

The first thing that comes to mind to fix this issue is to set the HttpContext property with a mock. But I cannot do that because this property is read only and thus I am not able to set it when doing the instantiation of the controller in the test method.

And if you need to mock the HttpContext class, you cannot because it is sealed. To avoid this you can use the HttpContextBase abstract class instead but in a test environment you will have to implement it in order to mock it and you don’t want to do this. Why? Because it’s a pain to do, you will have to provide implementation for everything, it’s like creating an entire web context just for the test. And in my case I just need the user languages.

So? What now? Do we give up testing our controllers? Absolutely not, it is possible to achieve our goal without too much complications. From the beginning I tried to mock the wrong thing. What I need is the user languages not the HttpContext, so let’s remove this dependency. I created the following interface with the data my code will use:

public interface IWebContext
{
    string[] UserLanguages { get; }
}

And now I will inject this interface in my Controller and I will create a specific implementation that will use the HttpContext to retrieve the languages from the request:

public class RealContext : IWebContext
{
    private HttpContext _context;
 
    public RealContext(HttpContext context)
    {
        _context = context;
    }
 
    public string[] UserLanguages
    {
        get { return _context.Request.UserLanguages; }
    }
}
 
public class IndexController : Controller
{
    IWebContext _context;
 
    public IndexController()
        : this(new RealContext(System.Web.HttpContext.Current)) { }
 
    public IndexController(IWebContext context)
    {
        _context = context;
    }
 
    [HttpGet]
    public ActionResult Index()
    {
        string[] languages = _context.UserLanguages;
        return View(model:languages);
    }
}

Note that I created a parameters-less constructor that instantiate the dependency, without this constructor the ASP .NET MVC will not be able to create the Controller (it won’t even compile).

I can now update my test by using a mock for my interface:

public class MockContext : IWebContext
{
    public string[] UserLanguages
    {
        get { return new string[1]; }
    }
}
 
[TestClass]
public class IndexControllerTest
{
    [TestMethod]
    public void IndexActionTest()
    {
        IndexController controller = new IndexController(new MockContext());
        ViewResult view = controller.Index() as ViewResult;
        Assert.IsNotNull(view);
    }
}

My test is now passing! I removed the dependency between the test and the web context objects, I can now test the logic of my controller without having to set up an awful lot of mocks.

I encapsulated my specific logic inside an abstraction that is far easier to mock. This way I was able to reduced the coupling, I was also able to increase my code coverage and all of it without losing any behavior.

You can use this technique for other properties of the HttpContext like the user agent if you want to apply some logic on it and test it. Or also for static classes/methods (that you can maybe found in your legacy code).

I hope this will help you and as usual do not hesitate to leave a comment.

See you next time!

Model validation in ASP .NET MVC

form-validation

I worked for several years as an ASP .NET MVC developer and I still do even if I do less front-end development at the moment. During my professional life I came across a few tips for this technology that helped me making my code cleaner and less coupled.

Before creating this blog I owned another one in french where I posted a few articles related to Model validation for a form. I will expose the concept of these articles in this new blog post, in english this time. Maybe it will look obvious for you but I wish I knew these tips when I started working with ASP .NET MVC and this is why I’m creating this blog entry, it might help some of you.

The problem

I created the following form for example, which ask for a name and an IP address:

I created this form using a new empty MVC application in Visual Studio and here is the Index.cshtml view:

@model CodingTips.Web.Models.IPAddressModel
 
<h2>IP Address form</h2>
@using (Html.BeginForm())
{
    @Html.AntiForgeryToken()
    <div>
        @Html.LabelFor(m => Model.Name):
    </div>
    <div>
        @Html.TextBoxFor(m => Model.Name)
        @Html.ValidationMessageFor(m => Model.Name)
    </div>
    <div>
        @Html.LabelFor(m => Model.IPAddress):
    </div>
    <div>
        @Html.TextBoxFor(m => Model.IPAddress)
        @Html.ValidationMessageFor(m => Model.IPAddress)
    </div>
    <input type="submit" />
}

The Model and the Controller are defined the following way at the moment:

public class IPAddressModel
{
    [Required]
    [Display(Name = "Your name")]
    public string Name { get; set; }
 
    [Required]
    [Display(Name = "Your IP address")]
    public string IPAddress { get; set; }
}
 
public class HomeController : Controller
{
    [HttpGet]
    public ActionResult Index()
    {
        return View();
    }
 
    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult Index(IPAddressModel model)
    {
        if (!ModelState.IsValid)
        {
            return View(model);
        }
 
        return RedirectToAction("Validate");
    }
 
    [HttpGet]
    public string Validate()
    {
        return "Your IP address has been registered";
    }
}

As you can see I already put some validation logic that will only verify that the fields are not left empty. If the user fill the two text boxes he will be redirected to a page containing only a confirmation message, this is the final result.

But, as you probably guessed it, there are issues with this validation code, the IP address field can be filled with any string value and the Model will be valid. This is not what we desire, we want a more accurate validation for this field and this is what I will show in this article.

When I began working with ASP .NET MVC my first thought, when I encountered an issue like this one, was to add all the validation logic inside the POST action of the Controller. Well, it can work but this is not the place to do so, this option increase the code coupling especially when the Model to validate is huge. In my opinion the Controller should only take care of the “flow” logic of the application and the validation should be placed somewhere else.

The good news is that ASP .NET MVC has been designed to be extensible for Model validation in an easy way. Let’s see how this can be done.

IValidatableObject

It is possible to add validation at the class-level, directly on the Model itself by implementing a specific interface: IValidatableObject. There is only one method available in this interface, the Validate() method. It will be automatically called by the MVC framework when the ModelState.IsValid code is executed, which is already present in our Controller. Let’s see the new version of the Model:

public class IPAddressModel : IValidatableObject
{
    [Required]
    [Display(Name = "Your name")]
    public string Name { get; set; }
 
    [Required]
    [Display(Name = "Your IP address")]
    public string IPAddress { get; set; }
 
    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        const string regexPattern = @"^([\d]{1,3}\.){3}[\d]{1,3}$";
        var regex = new Regex(regexPattern);
 
        if (!regex.IsMatch(IPAddress))
            yield return new ValidationResult("IP address format is invalid", new[] { "IPAddress" });
    }
}

In this first implementation of the Validate() method I simply check that the given address match an IP V4 format (xxx.xxx.xxx.xxx). I have nothing else to do before being able to test this new behavior in my form.

ip-address-format-error

It works as expected. Yet, the validation is not over since I can put the value 800.800.800.800 (which is not valid for an IP address) without having any error, there is more validation to do:

public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
{
    const string regexPattern = @"^([\d]{1,3}\.){3}[\d]{1,3}$";
    var regex = new Regex(regexPattern);
 
    if (!regex.IsMatch(IPAddress))
        yield return new ValidationResult("IP address format is invalid", new[] { "IPAddress" });
 
    string[] values = IPAddress.Split(new[] { '.' }, StringSplitOptions.RemoveEmptyEntries);
 
    byte ipByteValue;
    foreach (string token in values)
    {
        if (!byte.TryParse(token, out ipByteValue))
            yield return new ValidationResult("IP address value is incorrect", new[] { "IPAddress" });
    }
}

I extended the Validate() method in order to add more logic and to check that each element of the IP address has a correct value. I did this by checking that each of them can be transformed into a byte (value from 0 to 255).

ip-address-value-error

By using the IValidatableObject interface I was able to add validation logic to my Model without modifying my Controller. Doing so can be helpful when you have validation logic that depends on several properties of the Model.

In our example I used this interface only to check a single property and therefore it can look a bit “overpowered”. And if I have another form with a IP address field I will need to extract this part of the logic into a specific method to avoid code duplication. This point leads me to my next tip.

Custom attribute

To add validation to a specific field, the IP address one in our case, my advice will be to create a custom validation attribute. This will allow me to put the validation logic in one place only. Here’s the attribute implementation:

public class IpAddressAttribute : RegularExpressionAttribute
{
    public IpAddressAttribute()
        : base(@"^([\d]{1,3}\.){3}[\d]{1,3}$")
    {}
 
    public override bool IsValid(object value)
    {
        if (!base.IsValid(value))
            return false;
 
        string ipValue = value as string;
        if (IsIpAddressValid(ipValue))
            return true;
 
        return false;
    }
 
    private bool IsIpAddressValid(string ipAddress)
    {
        if (string.IsNullOrEmpty(ipAddress))
            return false;
 
        string[] values = ipAddress.Split(new[] { '.' }, StringSplitOptions.RemoveEmptyEntries);
 
        byte ipByteValue;
        foreach (string token in values)
        {
            if (!byte.TryParse(token, out ipByteValue))
                return false;
        }
 
        return true;
    }
 
    public override string FormatErrorMessage(string name)
    {
        return string.Format("The '{0}' field has an invalid format.", name);
    }
}

The logic is exactly the same as the one present in the IValidatableObject chapter. First checking the overall format with a regular expression and this is why I created a RegularExpressionAttribute subtype. Then the value of each byte is checked. Now I can use this attribute on my Model:

public class IPAddressModel
{
    [Required]
    [Display(Name = "Your name")]
    public string Name { get; set; }
 
    [IpAddress]
    [Required]
    [Display(Name = "Your IP address")]
    public string IPAddress { get; set; }
}

The Controller is unchanged, the Model is much cleaner and I can easily reuse my attribute for each IP address property in my application models without duplicating the logic.

My Model is now fully checked but only on the server-side, and this validation can clearly be done on the client-side as well with some JavaScript. This will avoid unnecessary HTTP requests between the browser and the server.

jQuery validation

ASP .NET now integrates a lot of third-party JavaScript libraries and among them there is jQuery which we will use to achieve client-side validation. I updated the _Layout.cshtml view to add the following lines:

<script src="http://ajax.aspnetcdn.com/ajax/jQuery/jquery-2.1.3.min.js"></script>
<script src="http://ajax.aspnetcdn.com/ajax/jquery.validate/1.13.0/jquery.validate.min.js"></script>
<script src="http://ajax.aspnetcdn.com/ajax/mvc/5.1/jquery.validate.unobtrusive.min.js"></script>

You can find different versions of these script here if you need specific ones. You also have to check that the Web.config is configured in order to enable client-side validation with jQuery:

<configuration>
  <appSettings>
    <add key="ClientValidationEnabled" value="true"/>
    <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
  </appSettings>
  ...
</configuration>

I can test the form again and see what is happening.

ip-address-jquery

The data have been checked without posting them to the server. This is possible because the @Html.TextBoxFor() method has generated the following HTML for the IP address field:

<input data-val="true" data-val-required="The Your IP address field is required." id="IPAddress" name="IPAddress" type="text" value="" aria-required="true" class="input-validation-error" aria-describedby="IPAddress-error IPAddress-error" aria-invalid="true">

The data-val-* attributes (HTML5) are used by the jquery.validate plugin to perform the client-side validation. But as you can see, there is nothing related to our regular expression pattern we defined for the IPAddressAttribute. And if you try to validate the form with an invalid IP address the form will still be posted to the server. At the moment the client-site validation is not complete.

IClientValidatable

ASP .NET MVC allow us to extend the generated HTML in order to add more control over the fields in the form. For that I will make the IpAddressAttribute implementing the IClientValidatable interface.

public class IpAddressAttribute : RegularExpressionAttribute, IClientValidatable
{
    public IpAddressAttribute()
        : base(@"^([\d]{1,3}\.){3}[\d]{1,3}$")
    {}
 
    public override bool IsValid(object value)
    {
        // does not change
        ...
    }
 
    private bool IsIpAddressValid(string ipAddress)
    {
        // does not change
        ...
    }
 
    public override string FormatErrorMessage(string name)
    {
        return string.Format("The '{0}' field has an invalid format.", name);
    }
 
    public IEnumerable<ModelClientValidationRule> GetClientValidationRules(ModelMetadata metadata, ControllerContext context)
    {
        string fieldName = metadata.DisplayName;
        string errorMessage = string.Format("The '{0}' field has an invalid format.", fieldName);
        const string pattern = @"^([\d]{1,3}\.){3}[\d]{1,3}$";
 
        ModelClientValidationRegexRule patternRule = new ModelClientValidationRegexRule(errorMessage, pattern);
        yield return patternRule;
 
        ModelClientValidationRule ipRule = new ModelClientValidationRule();
        ipRule.ValidationType = "ipformat";
        ipRule.ErrorMessage = string.Format("The '{0}' field has an invalid value.", fieldName);
 
        yield return ipRule;
    }
}

This method adds two new validation rule for the client-side code. The first one is for the regular expression and I use the existing ModelClientValidationRegexRule class to do so. The second one is a custom ModelClientValidationRule for which I defined the type as “ipformat”. This means that the input in the form will have a data-val-ipformat attribute.

This attribute is not recognized by the jQuery validation plugin, so I created a IPFormat.js file to extend it:

$.validator.unobtrusive.adapters.addBool("ipformat");
 
$.validator.addMethod("ipformat", function (value, element) {
    if (!value) {
        return false;
    }
    var bytes = value.split(".");
    if (bytes.length != 4) {
        return false;
    }
    for (i in bytes) {
        var entry = bytes[i];
        if (!entry) {
            return false;
        }
        var byte = parseInt(entry);
        if (isNaN(byte) || byte < 0 || byte > 255){
            return false;
        }
    }
    return true;
});

After including this file in my _Layout.cshtm view, I can see that the generated HTML for the text box has changed.

<script src="~/Scripts/Validators/IPFormat.js"></script>
<input data-val="true" data-val-ipformat="The 'Your IP address' field has an invalid value." data-val-regex="The 'Your IP address' field has an invalid format." data-val-regex-pattern="^([\d]{1,3}\.){3}[\d]{1,3}$" data-val-required="The Your IP address field is required." id="IPAddress" name="IPAddress" type="text" value="" aria-required="true" aria-invalid="true" class="input-validation-error" aria-describedby="IPAddress-error">

I now have my attributes for the regular expression validation and for the ipformat validation. Let’s try the form once again.

ip-address-jquery-custom

Here we are, the IP address is fully checked without being sent to the server. To achieve this I only used functionalities present in the framework, such as the IValidatableObject interface, the custom validation attributes, the IClientValidatable interface and a bit of jQuery.

This is the end of this blog post about Model validation in ASP .NET MVC on both server-side and client-side. I hope this will help you and as usual do not hesitate to comment and share this.

See you next time!

Extending mocking with Moq

simulator

In the last part of my Dependency Injection article I introduced the term of “mocking”. This kind of test double can be really powerful. Yet in my example I had to create 2 new classes (my mocks) to be able to test my functionality in order to reduced coupling. Here is the code used by the tests:

class MockNotifier : INotifier
{
    public MockNotifier()
    {
        NotifyHasBeenCalled = false;
    }
 
    public bool NotifyHasBeenCalled { get; private set; }
 
    public void Notify(User user)
    {
        NotifyHasBeenCalled = true;
    }
}
 
class MockRepository : IUserRepository
{
    public bool HasValidatedNotification { get; set; }
 
    public User GetById(int userId)
    {
        return new User { HasActivatedNotification = HasValidatedNotification };
    }
}
 
[TestClass]
public class NotificationServiceTest
{
    private NotificationService _notificationService;
    private MockNotifier _mockNotifier;
    private MockRepository _mockRepository;
 
    [TestInitialize]
    public void TestInit()
    {
        _mockNotifier = new MockNotifier();
        _mockRepository = new MockRepository();
        _notificationService = new NotificationService(_mockRepository, _mockNotifier);
    }
 
    [TestMethod]
    public void NotificationActivated()
    {
        _mockRepository.HasValidatedNotification = true;
        _notificationService.NotifyUser(1);
        Check.That(_mockNotifier.NotifyHasBeenCalled).IsTrue();
    }
 
    [TestMethod]
    public void NotificationDeactivated()
    {
        _mockRepository.HasValidatedNotification = false;
        _notificationService.NotifyUser(1);
        Check.That(_mockNotifier.NotifyHasBeenCalled).IsFalse();
    }
}

I think that being able to write its own mocks is a great exercise to understand Oriented Object Programming (OOP) in a testing context. But in a larger application it is likely that you will have an enormous amount of them, it is a lot of code to maintain. This is why I will introduce a mocking framework name Moq.

I used this nuget package for a few months now and it offers a lot of helpful functionalities. But I think that it can be a bit complex to use at first when people are not familiar with the mocking technique. Let’s see how the previous code can be refactored when using Moq:

[TestClass]
public class NotificationServiceTest
{
    private NotificationService _notificationService;
    private Mock<INotifier> _mockNotifier;
    private Mock<IUserRepository> _mockRepository;
 
    private User _fakeUser;
 
    [TestInitialize]
    public void TestInit()
    {
        _mockNotifier = new Mock<INotifier>();
        _mockRepository = new Mock<IUserRepository>();
        _notificationService = new NotificationService(_mockRepository.Object, _mockNotifier.Object);
        _fakeUser = new User();
 
        _mockRepository.Setup(m => m.GetById(It.IsAny<int>())).Returns(_fakeUser);
    }
 
    [TestMethod]
    public void NotificationActivated()
    {
        _fakeUser.HasActivatedNotification = true;
        _notificationService.NotifyUser(It.IsAny<int>());
        _mockNotifier.Verify(m => m.Notify(It.IsAny<User>()), Times.Once());
    }
 
    [TestMethod]
    public void NotificationDeactivated()
    {
        _fakeUser.HasActivatedNotification = false;
        _notificationService.NotifyUser(It.IsAny<int>());
        _mockNotifier.Verify(m => m.Notify(It.IsAny<User>()), Times.Never());
    }
}

First thing to be aware of is that the manipulated object are Mock instances and not implementations of the interfaces. It is possible to access these implementations by using the Object property of the Mock to inject the dependencies to a client object (NotificationService in this case). I also used the Setup method of the MockRepository to return a new instance of User when the GetById method is called.

Moq also provides a Verify method to check whether or not a method has been called and how many times. This is the method I used in the test to validate my test scenarios. You can notice that I no longer used NFluent, because in this case I don’t need it. Yet it is possible to use NFluent with Moq for the tests, they work really well together.

Last but not least, Moq provides powerful methods to match arguments, in my example it is the It.IsAny method. With this I can tell my Mock to accept any value as parameter because I am not testing it in my unit tests since it is irrelevant in this testing context.

This is just a quick overview of the possibilities offered by Moq and I encouraged you to check this awesome mocking framework.

See you next time !

Dependency Injection to the rescue

code-coupling

I am a developer, I believe in unit testing and I write a lot of them. But it was not always the case, mostly because I was working on a highly coupled code base. Whenever I wanted to test a single functionality I had to set up a lot of things (database, configuration files, …) to do so even if this functionality was not linked to these dependencies. It was spaghetti code into a big ball of mud.

Then I discovered the Dependency Injection (DI) pattern and it changed the way I designed my code and it made testing much easier. The DI purpose is to reduce coupling between software components in order to improve maintainability and testability. I created the following piece of code to demonstrate the principle :

public class User
{
    public string Name { get; set; }
    public string Email { get; set; }
    public bool HasActivatedNotification { get; set; }
}
 
public class EmailNotifier
{
    public void Notify(User user)
    {
        var message = string.Format("Hello {0} ...", user.Name);
        // Sending email
        // ...
    }
}
 
public class UserRepository
{
    public User GetById(int userId)
    {
        // Fetching information from datasource
        // ...
        return new User { Name = "John", Email = "john@john.com" };
    }
}
 
public class NotificationService
{
    public void NotifyUser(int userId)
    {
        var repository = new UserRepository();
        var user = repository.GetById(userId);
 
        if (user.HasActivatedNotification)
        {
            var notifier = new EmailNotifier();
            notifier.Notify(user);
        }
    }
}

The NotificationService sends an email to a given user if he has activated the notifications. Now if I want to test this logic I will have to set up a datasource for my repository and a mail inbox for the notifier. This is a lot of configuration for a simple piece of logic. This code is highly coupled because the NotifyUser method of my service instantiates its dependencies (the repository and the notifier), this means that the Single Responsibility Principle (SRP) is not respected. I will use the Constructor Injection technique to change the code :

public interface INotifier
{
    void Notify(User user);
}
 
public class EmailNotifier : INotifier
{
    public void Notify(User user)
    {
        var message = string.Format("Hello {0} ...", user.Name);
        // Sending email
        // ...
    }
}
 
public interface IUserRepository
{
    User GetById(int userId);
}
 
public class UserRepository : IUserRepository
{
    public User GetById(int userId)
    {
        // Fetching information from datasource
        // ...
        return new User { Name = "John", Email = "john@john.com" };
    }
}
 
public class NotificationService
{
    public NotificationService(IUserRepository repository, INotifier notifier)
    {
        _repository = repository;
        _notifier = notifier;
    }
 
    private readonly IUserRepository _repository;
    private readonly INotifier _notifier;
 
    public void NotifyUser(int userId)
    {
        var user = _repository.GetById(userId);
 
        if (user.HasActivatedNotification)
        {
            _notifier.Notify(user);
        }
    }
}

The UserRepository and the EmailNotifier are unchanged, they just implement interfaces. Now the NotificationService uses these interfaces as fields that are injected through the constructor. The NotifyUser method can now use these dependencies without having to create them, the code is “cleaner”.

I added interfaces for the repository and the notifier for testing purpose, I can test my service with a fake repository and a fake notifier that do not require heavy configuration :

class MockNotifier : INotifier
{
    public MockNotifier()
    {
        NotifyHasBeenCalled = false;
    }
 
    public bool NotifyHasBeenCalled { get; private set; }
 
    public void Notify(User user)
    {
        NotifyHasBeenCalled = true;
    }
}
 
class MockRepository : IUserRepository
{
    public bool HasValidatedNotification { get; set; }
 
    public User GetById(int userId)
    {
        return new User { HasActivatedNotification = HasValidatedNotification };
    }
}

These two implementations are mocks, it means that they mimic the behavior of concrete classes and are used only for testing purpose. In my MockNotifier I just set a flag to true when the Notify method is called, and the GetById method of the MockRepository returns a User instance with the wanted value for HasActivatedNotification. I created a test class with NFluent to show how it is used :

[TestClass]
public class NotificationServiceTest
{
    private NotificationService _notificationService;
    private MockNotifier _mockNotifier;
    private MockRepository _mockRepository;
 
    [TestInitialize]
    public void TestInit()
    {
        _mockNotifier = new MockNotifier();
        _mockRepository = new MockRepository();
        _notificationService = new NotificationService(_mockRepository, _mockNotifier);
    }
 
    [TestMethod]
    public void NotificationActivated()
    {
        _mockRepository.HasValidatedNotification = true;
        _notificationService.NotifyUser(1);
        Check.That(_mockNotifier.NotifyHasBeenCalled).IsTrue();
    }
 
    [TestMethod]
    public void NotificationDeactivated()
    {
        _mockRepository.HasValidatedNotification = false;
        _notificationService.NotifyUser(1);
        Check.That(_mockNotifier.NotifyHasBeenCalled).IsFalse();
    }
}

I can test the logic of my service without having to configure a datasource with pre-configured users and without checking in a inbox if there is an email or not. Dependency Injection reduces code coupling and makes testing easier even if you have to create dedicated classes for them. You can find more information about DI here and here.

Constructor Injection is a pattern I use because with it I improved the maintainability of my code base with less coupling and more testing, you should try it as well if it’s not the case.

See you next time !

Coding Tips – Regex optimization in C#

coding-tipIn programming, manipulating strings can have serious impacts on your program performance, especially when using regular expression (regex). From what I found (links at the end), C# is not the best programming language to do this kind of operations.

I am not a regex expert but I know some tricks to increase performance when using them in .NET with C#. And this is what I’ll show you in this blog post. I started with the following piece of code :

public static class RegexComparer
{
    private const string REGEX_PATTERN = @"^[\w\d]+$";
    private const string REGEX_INPUT = "azertyuiop7894561230qsdfghjklm7894561230wxcvbn7894561230";
 
    public static bool StaticRegexMatch()
    {
        var match = Regex.Match(REGEX_INPUT, REGEX_PATTERN);
        return match.Success;
    }
}

The StaticRegexMatch() method will verify that the input is only made of alphanumeric characters by using the Regex class in a static way. I made a program that executes this function 500,000 times in a row and this is the result I get when looking at the execution time :

Static Regex Match
Executing action 500000 times
Elapsed time (ms) : 2713
Result is True

After this, I used the following code :

public static bool StaticCompiledRegexMatch()
{
    var match = Regex.Match(REGEX_INPUT, REGEX_PATTERN, RegexOptions.Compiled);
    return match.Success;
}
Static Compiled Regex Match
Executing action 500000 times
Elapsed time (ms) : 2404
Result is True

I gain in performance because knowing that the regex will be used several time I used the Compiled value of the RegexOptions parameter to specify the application to  store the regex in an assembly.

Last but not least solution :

private static Regex CompiledRegexInstance = new Regex(REGEX_PATTERN, RegexOptions.Compiled);
 
public static bool CompiledRegexInstanceMatch()
{
    var match = CompiledRegexInstance.Match(REGEX_INPUT);
    return match.Success;
}
Compiled Regex Instance Match
Executing action 500000 times
Elapsed time (ms) : 2317
Result is True

This time I used a specific instance in my class to match the input instead of the static Match() method and I kept the Compiled option. The performance gap is not as important as the first time but it is still better.

The pattern to match I chose in this example is quite simple and I can improve the performance of my code by using a different technique :

public static bool LinqMatch()
{
    return REGEX_INPUT.All(c => char.IsLetterOrDigit(c));
}
Linq Match
Executing action 500000 times
Elapsed time (ms) : 749
Result is True

As you can see, this approach is much more effective. The .NET char has several useful methods to validate data and combined with LINQ it can be very helpful for string operations.

Regular expressions are powerful features but are costly regarding execution time. Yet there are ways to improve their performance and sometimes the best answer is to avoid them if you can, depending on the pattern you want to match.

EDIT : You can find a link to a version of these examples with improvements on a gist made by Cybermaxs which I really thank (his answer is in the comments section).

Programming languages benchmark links :

As always, do not hesitate to share your ideas/remarks regarding this topic.

See you next time !

Are you a software Boy Scout ?

boy-scout

If you are a developer like me, you probably worked on a legacy code based application. If not, don’t worry (or do) it will certainly happen… We all know a project that we fear to open because it is just a huge mess without a single test and nobody really understand how it works, it just does. Every software team has to work in order to prevent the effects of technical debt.

Refactoring a whole application to make the code “cleaner” can take an enormous amount of time, it can be weeks or sometimes months, depending on the project size and complexity. Some organization will incorporate refactoring phases during the development life-cycle. But since during these periods, the team does not provide any new features (i.e. no value), having these refactoring phases is a hard sell. Time to become a Boy Scout then !

What the boys scouts have to do with software development ? The answer is found in their rule :

“Always leave the campground cleaner than you found it.”

This simple rule can be applied to code and especially legacy code, and it becomes :

“Leave the code better than you found it.”

I present you the Boy Scout Rule (BSR) of programming. Making the code “cleaner” can be done at any moment, and it can be done piece by piece, no need to wait for a “Big Bang Refactoring” phase.

If you have a legacy project it is likely that you will have some improvements or bug fixing to do in it. This is the perfect time to embrace the boy scout philosophy. Of course after your passage the application will still be legacy but a bit less, and the next time you will improve it again. The code will become better with time and one day you’ll stop considering the project as a legacy one.

For example it is possible to rename a variable with a more meaningful name. Given the following code to calculate a triangle area :

var res = b / 2 * h

After the BSR applied :

var triangleArea = base / 2 * height

This is not much but it will help the next developer (maybe you) to understand the code and its purpose. And next time you will see that this piece of code is duplicate in several parts of the code. Time to create a method then :

public int CalculateTriangleArea(int base, int height)
{
    return base / 2 * height;
}

You now have a method that can replace your duplicate code and that can be easily tested with your favorite automated testing framework ! I know that this example is really simple but I’m sure you’ll find these kinds of easy “cleaning” in your applications.

There is a type of code refactoring I often use to make my code more understandable and to ease maintainability : moving repeated magic number value into a single constant variable. For example, a few years back, the french VAT was equal to 19.6% and now it is 20%. I let you imagine the pain it could have been to change every “19.6” in some projects where it could have been far easier to use a single constant with a meaningful name.

There are a lot of refactoring techniques to improve your code base, Martin Fowler gives you a list of some of them here.

A software craftsman does not fear legacy code, by following the Boy Scout Rule he will improve his projects.

See you next time !