The code used in this post is available here.

Remember in order to run the code or to create unit tests shown in this post you need to download and install:

• Microsoft ADO.NET Entity Framework Feature Community Technology Preview 4
• Microsoft SQL Server Compact 4.0 Community Technology Preview for Windows Desktop

Getting started

The entities we will be using are the same Dinner and RSVP entities Scott used in his post

public class Dinner
{
    public int DinnerID { get; set; }
    public string Title { get; set; }
    public DateTime EventDate { get; set; }
    public string Address { get; set; }
    public string Country { get; set; }
    public string HostedBy { get; set; }

    public virtual ICollection<RSVP> RSVPs { get; set; }
}

public class RSVP
{
    public int RsvpID { get; set; }
    public int DinnerID { get; set; }
    public string AtendeeEmail { get; set; }

    public virtual Dinner Dinner { get; set; }
}

as well as the NerdDinners class which inherits from DbContext

public class NerdDinners : DbContext
{
    public DbSet<Dinner> Dinners { get; set; }
    public DbSet<RSVP> RSVP { get; set; }
}

Creating Entity Framework Code-First Unit Tests

So let’s start off by writing a test to check a Dinner can be saved in the database.

[Test]
public void Should_be_able_to_save_new_dinner()
{
    // Arrange
    Database.DefaultConnectionFactory = new SqlCeConnectionFactory("System.Data.SqlServerCe.4.0");
    NerdDinners nerdDinners = new NerdDinners();

    Dinner dinner = new Dinner
                        {
                            Title = "Dinner with the Queen",
                            Address = "Buckingham Palace",
                            EventDate = DateTime.Now,
                            HostedBy = "Liz and Phil",
                            Country = "England"
                        };

    nerdDinners.Dinners.Add(dinner);

    // Act
    nerdDinners.SaveChanges();

    // Assert
    Dinner savedDinner = (from d in nerdDinners.Dinners
                            where d.DinnerID == dinner.DinnerID
                            select d).Single();

    savedDinner.Title.ShouldEqual(dinner.Title);
    savedDinner.Address.ShouldEqual(dinner.Address);
    savedDinner.EventDate.ShouldEqual(dinner.EventDate);
    savedDinner.HostedBy.ShouldEqual(dinner.HostedBy);
    savedDinner.Country.ShouldEqual(dinner.Country);
}

There are a couple of things to note here.

In the LINQ query to get the saved Dinner from the database we can use the ID of the Dinner we created because when you call the SaveChanges() method the Entity Framework will set the identity value of the object(s) being persisted.

The other thing we could have done is use a ‘domain signature’ to check for equality, but that’s for a future blog post.

Testing entities with foreign keys

The code below shows a test for saving an RSVP.

[Test]
public void Should_be_able_to_save_new_rsvp()
{
    // Arrange
    Database.DefaultConnectionFactory = new SqlCeConnectionFactory("System.Data.SqlServerCe.4.0");
    NerdDinners nerdDinners = new NerdDinners();

    RSVP rsvp = new RSVP();
    rsvp.AtendeeEmail = "someone@somedomain.com";
    Dinner dinner = new Dinner
                        {
                            Title = "Dinner with the Queen",
                            Address = "Buckingham Palace",
                            EventDate = DateTime.Now,
                            HostedBy = "Liz and Phil",
                            Country = "England"
                        };
    rsvp.Dinner = dinner;

    nerdDinners.RSVP.Add(rsvp);

    // Act
    nerdDinners.SaveChanges();

    // Assert
    RSVP savedRSVP = (from s in nerdDinners.RSVP
                        where s.RsvpID == rsvp.RsvpID
                        select s).Single();

    savedRSVP.AtendeeEmail.ShouldEqual(rsvp.AtendeeEmail);
}

One thing you might have noticed here is that we had to create a Dinner as well as an RSVP. This is because of the foreign key constraint for the DinnerID.

So at this point you could be asking why we can’t use the Dinner we created in the first test? The trouble, danger and bad practice of doing that is falling into the trap of creating a dependency of your tests running in some sort of order or sequence.

AlwaysRecreateDatabase

In his post Scott created a NerdDinnersInitializer class which inherited from RecreateDatabaseIfModelChanges. But this is not good enough for a unit test because we need to ensure each test starts off in a known state.

This doesn’t mean we have to create a Dinner each time we want to save an RSVP because we can create an NerdDinnersInitializer which is already populated with a dinner by overriding the Seed method.

public class NerdDinnersInitializer : AlwaysRecreateDatabase<NerdDinners>
{
    protected override void Seed(NerdDinners context)
    {
        var dinners = new List<Dinner> { new Dinner()
                                                {
                                                    Title = "Dinner with the Queen",
                                                    Address = "Buckingham Palace",
                                                    EventDate = DateTime.Now,
                                                    HostedBy = "Liz and Phil",
                                                    Country = "England"
                                                }
        };
        dinners.ForEach(d => context.Dinners.Add(d));
    }
}

And use it in a test to check we can create an RSVP

[Test]
public void Should_be_able_to_save_new_rsvp_using_existing_dinner()
{
    // Arrange
    Database.DefaultConnectionFactory = new SqlCeConnectionFactory("System.Data.SqlServerCe.4.0");
    Database.SetInitializer<NerdDinners>(new NerdDinnersInitializer());
    NerdDinners nerdDinners = new NerdDinners();

    RSVP rsvp = new RSVP();
    rsvp.AtendeeEmail = "someone@somedomain.com";
    rsvp.DinnerID = nerdDinners.Dinners.First().DinnerID;

    nerdDinners.RSVP.Add(rsvp);

    // Act
    nerdDinners.SaveChanges();

    // Assert
    RSVP savedRSVP = (from s in nerdDinners.RSVP
                        where s.RsvpID == rsvp.RsvpID
                        select s).Single();

    savedRSVP.AtendeeEmail.ShouldEqual(rsvp.AtendeeEmail);
}

The disadvantage of always creating a database is the amount of time it takes to actually create the database

So the more times you call SetInitializer in which you’re always recreating a database, the longer it will take for your tests to run.

My recommendation is to create dummy/stub dinners upfront and call SetInitializer before you run the tests. In NUnit this is done in the TestFixtureSetUp as shown below.

[TestFixtureSetUp]
public void TestFixtureSetup()
{
    Database.SetInitializer<NerdDinners>(new NerdDinnersInitializer());
}

Tests to check updates

So now you can save a Dinner, the next test you might write is to check you can update it.

[Test]
public void Should_be_able_to_update_existing_dinner()
{
    // Arrange
    NerdDinners nerdDinners = new NerdDinners();

    Dinner dinner = nerdDinners.Dinners.First();
    dinner.HostedBy = "Charlie and Camilla";

    // Act
    nerdDinners.SaveChanges();

    // Assert
    Dinner savedDinner = (from d in nerdDinners.Dinners
                            where d.DinnerID == dinner.DinnerID
                            select d).Single();

    savedDinner.HostedBy.ShouldEqual(dinner.HostedBy);
}

Testing your models

The examples in this post follow the Entity Framework convention you get out of the box.

As we have already established the property DinnerID is a foreign key in the RSVP entity.

But if you forgot to add it, the Dinner property would always be null.

The test below verifies we are able to view information about a dinner when we retrieve an RSVP from the database.

[Test]
public void Should_be_able_to_view_dinner_details()
{
    // Arrange
    NerdDinners nerdDinners = new NerdDinners();
    var dinner = nerdDinners.Dinners.First();

    RSVP rsvp = new RSVP();
    rsvp.AtendeeEmail = "someone@somedomain.com";
    rsvp.DinnerID = dinner.DinnerID;

    nerdDinners.RSVP.Add(rsvp);

    // Act
    nerdDinners.SaveChanges();

    // Assert
    RSVP savedRSVP = (from s in nerdDinners.RSVP
                        where s.RsvpID == rsvp.RsvpID
                        select s).Single();

    savedRSVP.Dinner.Title.ShouldEqual(dinner.Title);
}

Jag Reehal’s Final Thought on ‘Examples of Code First Entity Framework Unit Tests’

In this post I wanted to show a few examples of how you might create unit tests for your Entity Framework projects.

The ADO.NET team have really done a great job enabling developers to be able to do code-first development and allow them to move a step closer to doing test driven development using the Entity Framework.

Like the IDataErrorInfo interface, the INotifyDataErrorInfo interface gives you the ability to do validation without throwing exceptions.

The full solution for this post can be downloaded here.

Note to WPF developers – INotifyDataErrorInfo isn’t available in WPF (yet)

But you can vote for INotifyDataErrorInfo to be in a future release of WPF.

Pre INotifyDataErrorInfo

As you can see in the code below we are throwing exceptions in the setters for the two values we want to add together.

public string  FirstValue
{
    get { return _firstValue; }
    set
    {
        _firstValue = value;
        try
        {
            int.Parse(_firstValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("FirstValue");
    }
}
public string  SecondValue
{
    get { return _secondValue; }
    set
    {
        _secondValue = value;
        try
        {
            int.Parse(_secondValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("SecondValue");
    }
}

Implementing the INotifyDataErrorInfo interface

As we only want the calculate button to be enabled when the user has entered valid numbers to add together, we need to keep track of any validation errors.

Similar to how we have done in other posts, we will use a class for storing validation errors instead of making it the responsibility of the ViewModel.

And that class is the EntityBase class, which I borrowed from Mike Taulty. Cheers Mike!

The code below shows how the EntityBase class implements the ErrorsChanged event, GetErrors method and the HasErrors property defined in the INotifyDataErrorInfo interface.

public class EntityBase : INotifyDataErrorInfo
{
    public event EventHandler<DataErrorsChangedEventArgs> ErrorsChanged;
    readonly Dictionary<string, List<string>> _currentErrors;

    public EntityBase()
    {
        _currentErrors = new Dictionary<string, List<string>>();
    }

    public IEnumerable GetErrors(string propertyName)
    {
        if (string.IsNullOrEmpty(propertyName))
        {
            return (_currentErrors.Values);
        }

        MakeOrCreatePropertyErrorList(propertyName);
        return _currentErrors[propertyName];
    }

    public bool HasErrors
    {
        get
        {
            return (_currentErrors.Where(c => c.Value.Count > 0).Count() > 0);
        }
    }

    void FireErrorsChanged(string property)
    {
        if (ErrorsChanged != null)
        {
            ErrorsChanged(this, new DataErrorsChangedEventArgs(property));
        }
    }
    public void ClearErrorFromProperty(string property)
    {
        MakeOrCreatePropertyErrorList(property);
        _currentErrors[property].Clear();
        FireErrorsChanged(property);
    }
    public void AddErrorForProperty(string property, string error)
    {
        MakeOrCreatePropertyErrorList(property);
        _currentErrors[property].Add(error);
        FireErrorsChanged(property);
    }

    void MakeOrCreatePropertyErrorList(string propertyName)
    {
        if (!_currentErrors.ContainsKey(propertyName))
        {
            _currentErrors[propertyName] = new List<string>();
        }
    }
}

The EnitityBase class can be unit tested like this

[TestFixture]
public class When_using_the_EntityBase
{
    private EntityBase _entityBase;

    [SetUp]
    public void SetUp()
    {
        _entityBase = new EntityBase();
    }

    [Test]
    public void HasErrors_should_return_true_when_errors_exist()
    {
        // Arrange
        _entityBase.AddErrorForProperty("X", "X");

        // Act
        var result = _entityBase.HasErrors;

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    public void HasErrors_should_return_true_when_no_errors_exist()
    {
        // Arrange
        // collection will be empty at this point

        // Act
        var result = _entityBase.HasErrors;

        // Assert
        result.ShouldBeFalse();
    }

    [Test]
    public void Should_be_able_to_clear_error_from_property()
    {
        // Arrange
        _entityBase.AddErrorForProperty("X", "X");

        // Act
        _entityBase.ClearErrorFromProperty("X");
        var result = _entityBase.GetErrors("X") as List<string>; 

        // Assert
        result.Count().ShouldEqual(0);

    }

    [Test]
    public void Should_be_able_to_get_error_for_property()
    {
        // Arrange
        const string errorMessage = "ErrorMessage";
        _entityBase.AddErrorForProperty("X", "ErrorMessage");

        // Act
        var result =  _entityBase.GetErrors("X") as List<string>;

        // Assert
        result[0].ShouldEqual(errorMessage);

    }
}

How the ViewModel validates user input

We need to validate the users input each time the value of a property changes.

If you have been following the series you’ll know the benefits of injecting/importing a class responsible for validation, the CalculatorValidator, into the ViewModel and to validate the users input.

In the code for the CalculatorValidator class, the Validate method could have returned a collection of error messages, but to keep this example simple we’ll just return the first validation error we encounter.

[Export(typeof(ICalculatorValidator))]
public class CalculatorValidator : ICalculatorValidator
{
    [ImportMany]
    public IEnumerable<ICalculatorValidationRule> CalculatorValidationRules { get; set; }

    public ValidationResult Validate(string value)
    {
        List<ValidationResult> validationResults = new List<ValidationResult>();
        foreach (var calculatorValidationRule in CalculatorValidationRules)
        {
            if (!calculatorValidationRule.IsValid(value))
            {
                return new ValidationResult()
                            {
                                IsValid = false,
                                ErrorMessage = calculatorValidationRule.ErrorMessage

                            };
            }
        }
        return new ValidationResult() { IsValid = true };
    }
}

public class ValidationResult
{
    public bool IsValid { get; set; }
    public string ErrorMessage { get; set; }
}

If you’re new to the series the validation rules for calculator are being imported by MEF. Read how and why we are doing this in the ‘Applying the Open Closed Principle in Silverlight and WPF using MEF‘ post.

Using the INotifyDataErrorInfo interface in the ViewModel

In the code for the ViewModel shown below take note of how:

• the ViewModel inherits from the EntityBase class
• the CheckIfNumberIsValid method is called whenever a property value changes
• the INotifyDataErrorInfo HasErrors property is used to determine if the button should be enabled in the CalculatorViewModel_ErrorsChanged handler for the ErrorsChanged event. This is one of the advantages INotifyDataErrorInfo has over IDataErrorInfo.

[Export]
public class CalculatorViewModel : EntityBase, INotifyPropertyChanged
{
    private string _firstValue;
    private string _secondValue;
    private string _result;       

    private readonly ICalculator _calculator;
    private readonly RelayCommand _calculateCommand;

    public event PropertyChangedEventHandler PropertyChanged;
    public ObservableCollection<string> FirstValueErrors { get; set; }
    private readonly ICalculatorValidator _calculatorValidator;

    [ImportingConstructor]
    public CalculatorViewModel(ICalculator calculator, ICalculatorValidator calculatorValidator)
    {
        _calculator = calculator;
        _calculatorValidator = calculatorValidator;
        _calculateCommand = new RelayCommand(Calculate) { IsEnabled = true };
        ErrorsChanged += new EventHandler<DataErrorsChangedEventArgs>(CalculatorViewModel_ErrorsChanged);

        _firstValue = "0";
        _secondValue = "0";
    }

    void CalculatorViewModel_ErrorsChanged(object sender, DataErrorsChangedEventArgs e)
    {
        _calculateCommand.IsEnabled = HasErrors == false;
    }

    public void Calculate()
    {
        Result = _calculator.Add(Convert.ToInt32(FirstValue), Convert.ToInt32(SecondValue)).ToString();
    }

    public string FirstValue
    {
        get { return _firstValue; }
        set
        {
            _firstValue = value;
            CheckIfNumberIsValid("FirstValue", value);
        }
    }

    public string SecondValue
    {
        get { return _secondValue; }
        set
        {
            _secondValue = value;
            CheckIfNumberIsValid("SecondValue", value);
        }
    }

    public void CheckIfNumberIsValid(string propertyName, string value)
    {
        ClearErrorFromProperty(propertyName);

        var validationResult = _calculatorValidator.Validate(value);
        if (validationResult.IsValid  == false)
        {
            AddErrorForProperty(propertyName, validationResult.ErrorMessage);
        }
        OnPropertyChanged(propertyName);
    }

    public string Result
    {
        get { return _result; }
        private set
        {
            _result = value;
            OnPropertyChanged("Result");
        }
    }

    public RelayCommand CalculateCommand
    {
        get { return _calculateCommand; }
    }

    protected void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this,
                new PropertyChangedEventArgs(propertyName));
        }
    }
}

XAML changes for INotifyDataErrorInfo

The final change required to implement INotifyDataErrorInfo interface is to change the text box bindings and set ValidatesOnNotifyDataErrors=True

<TextBox Text="{Binding FirstValue, Mode=TwoWay, ValidatesOnNotifyDataErrors=True}"/>
<TextBox Text="{Binding SecondValue, Mode=TwoWay, ValidatesOnNotifyDataErrors=True}"/>

So what have we achieved?

In this post we have refactored the code to use the INotifyDataErrorInfo interface and are no longer throwing exceptions to do validation.

As well as allowing you return multiple validation errors for a property, the INotifyDataErrorInfo interface can be used for asynchronous data validation as demonstrated by Jesse Liberty in this video.

The IDataErrorInfo interface gives you the ability to do validation without throwing exceptions.

The full solution for this post can be downloaded here.

Pre IDataErrorInfo

As you can see in the code below we are throwing exceptions in the setters for the two values we want to add together.

public string  FirstValue
{
    get { return _firstValue; }
    set
    {
        _firstValue = value;
        try
        {
            int.Parse(_firstValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("FirstValue");
    }
}
public string  SecondValue
{
    get { return _secondValue; }
    set
    {
        _secondValue = value;
        try
        {
            int.Parse(_secondValue);
        }
        catch (Exception)
        {
            throw new Exception("That's not a number");
        }
        OnPropertyChanged("SecondValue");
    }
}

Implementing the IDataErrorInfo interface

The IDataErrorInfo interface consists of two properties.

string this[string columnName] {get;}
string Error {get;}

For the Error property we can just return null because we don’t want to return a single error message for the entire object.

public string Error
{
    get { return null; }
}

For the property which returns an error for a text box we could do the validation like this

public string this[string columnName]
{
    get
    {
        string error = null;
        switch (columnName)
        {
            case "FirstValue":
                try
                {
                    int.Parse(_firstValue);
                }
                catch (Exception)
                {
                    error = "That is not a number";
                }
                break;
            case "SecondValue":
                try
                {
                    int.Parse(_firstValue);
                }
                catch (Exception)
                {
                    error = "That is not a number";
                }
                break;
        }
        return error;
    }
}

But as we saw in a previous post about using ValidatesOnExceptions to do validation it’s much easier to write unit tests when there are separation of concerns and the ViewModel is not responsible for validation.

So this means we need to create a class for storing the validation error for each textbox

public class ValidationBase
{
    public readonly Dictionary<string, string> Errors;

    public ValidationBase()
    {
        Errors = new Dictionary<string, string>();
    }

    public void AddError(string propertyName, string message)
    {
        if (!Errors.ContainsKey(propertyName))
        {
            Errors[propertyName] = message;
        }
    }

    public void RemoveErrors(string propertyName)
    {
        Errors.Remove(propertyName);
    }

    public string GetErrorMessageForProperty(string propertyName)
    {
        string message;
        Errors.TryGetValue(propertyName, out message);
        return message;
    }

    public bool HasErrors()
    {
        return Errors.Count != 0;
    }
}

which is inherited by a CalculatorValidator class that returns a boolean value if the property value is not valid

[Export(typeof(ICalculatorValidator))]
public class CalculatorValidator : ValidationBase, ICalculatorValidator
{
    [ImportMany]
    public IEnumerable<ICalculatorValidationRule> CalculatorValidationRules { get; set; }

    public bool IsPropertyValid(string propertyName, string value)
    {
        RemoveErrors(propertyName);
        foreach (var calculatorValidationRule in CalculatorValidationRules)
        {
            if (!calculatorValidationRule.IsValid(value))
            {
                AddError(propertyName, calculatorValidationRule.ErrorMessage);
                return false;
            }
        }
        return true;
    }
}

If you’re new to the series the validation rules for calculator are being imported by MEF. Read how and why we are doing this in the ‘Applying the Open Closed Principle in Silverlight and WPF using MEF‘ post.

Now we can inject/import the CalculatorValidator into the ViewModel and use it to validate the users input.

As we only want the user to be able to click the calculate button when the form is valid we call we the CheckIfCalculteButtonShouldBeEnabled method when a text box value has changed.

[Export]
public class CalculatorViewModel : INotifyPropertyChanged, IDataErrorInfo
{
    private string _firstValue;
    private string _secondValue;
    private string _result;

    private readonly ICalculator _calculator;
    private readonly RelayCommand _calculateCommand;

    public event PropertyChangedEventHandler PropertyChanged;
    private readonly ICalculatorValidator _calculatorValidator;

    [ImportingConstructor]
    public CalculatorViewModel(ICalculator calculator, ICalculatorValidator calculatorValidator)
    {
        _calculator = calculator;
        _calculatorValidator = calculatorValidator;
        _calculateCommand = new RelayCommand(Calculate) { IsEnabled = true };

        _firstValue = "0";
        _secondValue = "0";
    }
    public void Calculate()
    {
        Result = _calculator.Add(Convert.ToInt32(FirstValue), Convert.ToInt32(SecondValue)).ToString();
    }

    public string FirstValue
    {
        get { return _firstValue; }
        set
        {
            _firstValue = value;
            OnPropertyChanged("FirstValue");
        }
    }

    public string SecondValue
    {
        get { return _secondValue; }
        set
        {
            _secondValue = value;
            OnPropertyChanged("SecondValue");
        }
    }

    public void CheckIfCalculteButtonShouldBeEnabled()
    {
        _calculateCommand.IsEnabled = _calculatorValidator.HasErrors() == false;
    }

    public string Result
    {
        get { return _result; }
        private set
        {
            _result = value;
            OnPropertyChanged("Result");
        }
    }

    public RelayCommand CalculateCommand
    {
        get { return _calculateCommand; }
    }

    protected void OnPropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this,
                new PropertyChangedEventArgs(propertyName));
        }
    }

    public string this[string columnName]
    {
        get
        {
            string error = null;
            switch (columnName)
            {
                case "FirstValue":
                    error = ValidateNumber("FirstValue", _firstValue);
                    break;
                case "SecondValue":
                    error = ValidateNumber("SecondValue", _secondValue);
                    break;
            }

            CheckIfCalculteButtonShouldBeEnabled();
            return error;
        }
    }

    public string ValidateNumber(string propertyName, string value)
    {
        if (!_calculatorValidator.IsPropertyValid(propertyName, value))
        {
            return _calculatorValidator.GetErrorMessageForProperty(propertyName);
        }
        return null;
    }

    public string Error
    {
        get { return null; }
    }
}

The code below shows how we can unit test the ViewModel which implements the IDataErrorInfo interface.

[TestFixture]
public class When_using_the_CalculatorViewModel
{
    private Mock<ICalculator> _calculator;
    private Mock<ICalculatorValidator> _calculatorValidator;
    private CalculatorViewModel _calculatorViewModel;

    [SetUp]
    public void SetUp()
    {
        _calculator = new Mock<ICalculator>();
        _calculatorValidator = new Mock<ICalculatorValidator>();
        _calculatorViewModel = new CalculatorViewModel(_calculator.Object, _calculatorValidator.Object);
    }

    [Test]
    public void Initial_value_of_first_number_is_0()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.FirstValue;

        // Assert
        result.ShouldEqual("0");
    }

    [Test]
    public void Initial_value_of_second_number_is_0()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.SecondValue;

        // Assert
        result.ShouldEqual("0");
    }

    [Test]
    public void Initial_value_of_calculate_button_is_enabled()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.CalculateCommand.IsEnabled;

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    public void ValidateNumber_returns_null_if_value_is_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.IsPropertyValid("X","X")).Returns(true);

        // Act
        var result = _calculatorViewModel.ValidateNumber("X","X");

        // Assert
        result.ShouldBeNull();
    }

    [Test]
    public void ValidateNumber_returns_error_message_if_value_is_not_valid()
    {
        // Arrange
        const string errorMessage = "ErrorMessageText";
        _calculatorValidator.Setup(c => c.IsPropertyValid("X", "X")).Returns(false);
        _calculatorValidator.Setup(c => c.GetErrorMessageForProperty("X")).Returns(errorMessage);

        // Act
        var result = _calculatorViewModel.ValidateNumber("X", "X");

        // Assert
        result.ShouldEqual(errorMessage);
    }

    [Test]
    public void Calculate_command_should_not_be_enabled_if_ViewModel_is_not_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.HasErrors()).Returns(true);

        // Act
        _calculatorViewModel.CheckIfCalculteButtonShouldBeEnabled();

        // Assert
        _calculatorViewModel.CalculateCommand.IsEnabled.ShouldBeFalse();
    }

    [Test]
    public void Calculate_command_should_be_enabled_if_ViewModel_is_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.HasErrors()).Returns(false);

        // Act
        _calculatorViewModel.CheckIfCalculteButtonShouldBeEnabled();

        // Assert
        _calculatorViewModel.CalculateCommand.IsEnabled.ShouldBeTrue();
    }
}

The final change we need to make is to change the text box binding to ValidatesOnDataErrors=True in the XAML file.

<TextBox Text="{Binding FirstValue, Mode=TwoWay, ValidatesOnDataErrors=True}"/>
<TextBox Text="{Binding SecondValue, Mode=TwoWay, ValidatesOnDataErrors=True}"/>

So what have we achieved?

In this post we have refactored the code to use the IDataErrorInfo interface and are no longer throwing exceptions to do validation.

Whether you choose to use it or not depends if you want multiple errors for a single property to be combined into a single error message.

While could validate the users input using exceptions, it wasn’t possible to disable the calculate button if the input values were invalid (because they were either blank or non-numeric).

The code used in this post can be downloaded here.

So how are we going to solve the problem?

Throughout the Silverlight refactoring series I’ve tried to illustrate how important SOLID design principles are for having testable applications.

So if we think about the ViewModel, we need to ask ourselves if it’s the right place or should be responsible for validation?

In this case I would say no.

When should the button be enabled?

For a calculate button to be enabled, both text boxes must contain numeric values

This means we have to know if both text boxes are valid at the same time. Taking a step back here, let’s think about the bigger picture.

What if there are three or four text boxes?

What we really after is a class that will be responsible for knowing if any text boxes are invalid.

This can be done by using a validation base class.

In the code below notice how the ValidationBase class doesn’t know anything about enabling or disabling the calculate button.

public class ValidationBase
{
    public readonly Dictionary<string, string> Errors;

    public ValidationBase()
    {
        Errors = new Dictionary<string, string>();
    }

    public void AddError(string propertyName, string message)
    {
        if (!Errors.ContainsKey(propertyName))
        {
            Errors[propertyName] = message;
        }
    }

    public void RemoveErrors(string propertyName)
    {
        Errors.Remove(propertyName);
    }

    public bool IsPropertyValid(string propertyName)
    {
        return !Errors.ContainsKey(propertyName);
    }

    public string GetErrorMessageForProperty(string propertyName)
    {
        string message;
        Errors.TryGetValue(propertyName, out message);
        return message;
    }

    public bool IsValid()
    {
        return Errors.Count == 0;
    }
}

The code below shows the unit tests for the ValidationBase class.

[TestFixture]
public class When_using_the_ValidatiorBase
{
    private ValidationBase _validationBase;

    [SetUp]
    public void SetUp()
    {
        _validationBase = new ValidationBase();
    }

    [Test]
    public void IsValid_should_return_false_when_errors_exist()
    {
        // Arrange
        _validationBase.AddError("propertyName", "message");

        // Act
        var result = _validationBase.IsValid();

        // Assert
        result.ShouldBeFalse();
    }

    [Test]
    public void IsValid_should_return_true_when_no_errors_exist()
    {
        // Arrange
        // collection will be empty at this point

        // Act
        var result = _validationBase.IsValid();

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    public void IsPropertyValid_should_return_false_if_error_exists()
    {
        // Arrange
        _validationBase.AddError("propertyName", "message");

        // Act
        var result = _validationBase.IsPropertyValid("propertyName");

        // Assert
        result.ShouldBeFalse();
    }

    [Test]
    public void IsPropertyValid_should_return_true_if_error_does_not_exist()
    {
        // Arrange
        // collection will be empty at this point

        // Act
        var result = _validationBase.IsPropertyValid("X");

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    public void Should_be_able_to_return_message_for_error()
    {
        // Arrange
        _validationBase.AddError("propertyName", "message");

        // Act
        var result = _validationBase.GetErrorMessageForProperty("propertyName");

        // Assert
        result.ShouldEqual("message");
    }

    [Test]
    public void Should_return_null_if_message_does_not_exist_for_error()
    {
        // Arrange
        // collection will be empty at this point

        // Act
        var result = _validationBase.GetErrorMessageForProperty("propertyName");

        // Assert
        result.ShouldBeNull();
    }
}

Validating the users input

There are three outcomes when validating what the user has entered:

• The value is blank
• The value is not a number
• The value is a number

All the ViewModel wants to know is if the users input is valid, choosing the appropriate error message isn’t its concern. This means we need a class that will be responsible for validation and returning the relevant message.

For this we will use the CalculatorValidator class we created in the ‘Applying the Open Closed Principle in Silverlight and WPF using MEF‘ post.

[Export(typeof(ICalculatorValidator))]
public class CalculatorValidator : ValidationBase, ICalculatorValidator
{
    [ImportMany]
    public IEnumerable<ICalculatorValidationRule> CalculatorValidationRules { get; set; }

    public void ValidateNumber(string propertyName, string value)
    {
        RemoveErrors(propertyName);

        foreach (var calculatorValidationRule in CalculatorValidationRules)
        {
            if (!calculatorValidationRule.IsValid(value))
            {
                AddError(propertyName, calculatorValidationRule.ErrorMessage);
                return;
            }
        }
    }
}

This is useful because if we decide to change how to validate the user’s input neither the CalculatorValidator or the ViewModel classes need to be modified.

Hooking it all up

To use the CalculatorValidator in the ViewModel it has to be injected/imported.

[ImportingConstructor]
public CalculatorViewModel(ICalculator calculator, ICalculatorValidator calculatorValidator)
{
    _calculator = calculator;
    _calculatorValidator = calculatorValidator;
    ...
}

Each time a user enters a value in the text boxes the CheckIfNumberIsValid method checks if the calculate button should be enabled and throws an exception if the users value is not valid.

public string FirstValue
{
    get { return _firstValue; }
    set
    {
        CheckIfNumberIsValid("FirstValue", out _firstValue, value);
    }
}

public string SecondValue
{
    get { return _secondValue; }
    set
    {
        CheckIfNumberIsValid("SecondValue", out _secondValue, value);
    }
}

public void CheckIfNumberIsValid(string propertyName, out string propertyValue, string value)
{
    _calculatorValidator.ValidateNumber(propertyName, value);

    CheckIfCalculteButtonShouldBeEnabled();

    if (_calculatorValidator.IsPropertyValid(propertyName))
    {
        propertyValue = value;
        OnPropertyChanged(propertyName);
    }
    else
    {
        throw new Exception(_calculatorValidator.GetErrorMessageForProperty(propertyName));
    }
}

public void CheckIfCalculteButtonShouldBeEnabled()
{
    _calculateCommand.IsEnabled = _calculatorValidator.IsValid();
}

Unit testing the ViewModel in MVVM

By using Moq we can unit test the ViewModel to ensure the button is enabled when there are no validation errors and not enabled when there are validation errors.

[TestFixture]
public class When_using_the_CalculatorViewModel
{
    private Mock<ICalculator> _calculator;
    private Mock<ICalculatorValidator> _calculatorValidator;
    private CalculatorViewModel _calculatorViewModel;

    [SetUp]
    public void SetUp()
    {
        _calculator = new Mock<ICalculator>();
        _calculatorValidator = new Mock<ICalculatorValidator>();
        _calculatorViewModel = new CalculatorViewModel(_calculator.Object, _calculatorValidator.Object);
    }

    [Test]
    public void Initial_value_of_first_number_is_0()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.FirstValue;

        // Assert
        result.ShouldEqual("0");
    }

    [Test]
    public void Initial_value_of_second_number_is_0()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.SecondValue;

        // Assert
        result.ShouldEqual("0");
    }

    [Test]
    public void Initial_value_of_calculate_button_is_enabled()
    {
        // Arrange
        // checking initial value

        // Act
        var result = _calculatorViewModel.CalculateCommand.IsEnabled;

        // Assert
        result.ShouldBeTrue();
    }

    [Test]
    [ExpectedException(typeof(Exception))]
    public void Will_throw_exception_if_input_is_invalid()
    {
        // Arrange
        string propertyValue;
        _calculatorValidator.Setup(c => c.IsPropertyValid("X")).Throws(new Exception());

        // Act
        _calculatorViewModel.CheckIfNumberIsValid("X", out propertyValue, "X");

        // Assert
        // should throw exception
    }

    [Test]
    public void Will_set_property_value_if_input_is_valid()
    {
        // Arrange
        string propertyValue;
        _calculatorValidator.Setup(c => c.IsPropertyValid("X")).Returns(true);

        // Act
        _calculatorViewModel.CheckIfNumberIsValid("X", out propertyValue, "11");

        // Assert
        propertyValue.ShouldEqual("11");

    }

    [Test]
    public void Calculate_command_should_not_be_enabled_if_ViewModel_is_not_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.IsValid()).Returns(false);

        // Act
        _calculatorViewModel.CheckIfCalculteButtonShouldBeEnabled();

        // Assert
        _calculatorViewModel.CalculateCommand.IsEnabled.ShouldBeFalse();
    }

    [Test]
    public void Calculate_command_should_be_enabled_if_ViewModel_is_valid()
    {
        // Arrange
        _calculatorValidator.Setup(c => c.IsValid()).Returns(true);

        // Act
        _calculatorViewModel.CheckIfCalculteButtonShouldBeEnabled();

        // Assert
        _calculatorViewModel.CalculateCommand.IsEnabled.ShouldBeTrue();
    }
}

So what have we achieved?

By using a validation base class we are able to store validation errors and can determine if the controls on the page are all valid.

The ViewModel can take advantage of this functionality and use it to enable and disable the calculate button.

Using exceptions for validation isn’t every developers cup of tea, so be sure to keep an eye on the Silverlight refactoring series to see other approaches we can take to do validation in Silverlight 4.

In this part of the Silverlight Refactoring series we will convert a ViewModel with multiple responsibilities so that it adheres to the Single Responsibility Principle (SRP).

The code used in this post can be downloaded here.

Why should you care?

Currently the ViewModel looks like this

using System;
using System.ComponentModel;
using System.Windows.Input;

namespace SilverlightCalculator
{
    public class CalculatorViewModel : INotifyPropertyChanged
    {
        private string _firstValue;
        private string _secondValue;
        private string _result;

        private readonly ICommand _calculateCommand;       

        public event PropertyChangedEventHandler PropertyChanged;

        public CalculatorViewModel()
        {
            _calculateCommand = new RelayCommand(Calculate){IsEnabled = true};
        }

        public void Calculate()
        {
            Result = (Convert.ToInt32(FirstValue) + Convert.ToInt32(SecondValue)).ToString();
        }

        public string FirstValue
        {
            get { return _firstValue; }
            set
            {
                _firstValue = value;
                OnPropertyChanged("FirstValue");
            }
        }

        public string SecondValue
        {
            get { return _secondValue; }
            set
            {
                _secondValue = value;
                OnPropertyChanged("SecondValue");
            }
        }

        public string Result
        {
            get { return _result; }
            private set
            {
                _result = value;
                OnPropertyChanged("Result");
            }
        }

        public ICommand CalculateCommand
        {
            get { return _calculateCommand; }
        }

        protected void OnPropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this,
                    new PropertyChangedEventArgs(propertyName));
            }
        }
    }
}

As you can see the logic to add two numbers is in the Calculate method of the ViewModel.

Therefore the ViewModel is responsible for calculating two numbers.

A ViewModel without separation of concerns is difficult to test, maintain and contains code you can’t reuse.

Although we’re only adding two numbers here, brushing the issue under the carpet will have consequences later down the line.

For example in addition to adding numbers what if another developer was given the task of storing the result in a database.

If the ViewModel was as it is now, with no separation of concerns, there is a chance they would put the code to store the value in the calculate method like this

public void Calculate()
{
    // Calculate result
    Result = (Convert.ToInt32(FirstValue) + Convert.ToInt32(SecondValue)).ToString();

    // Store value in database
    DatabaseConnection connection = new DatabaseConnection();
    DatabaseCommand command = new DatabaseCommand("TSQL TO STORE RESULT", connection);
    command.ExecuteNonQuery();
}

Now the ViewModel would be responsible for two things. Next it would be three and this would continue until someone decides to separate the concerns or it gets to a stage where it’s impossible to work with let alone read.

Refactoring the ViewModel to follow the single responsibility principle

Let’s start by creating a class for calculating numbers.

public class Calculator
{
    public int Add(int firstValue, int secondValue)
    {
        return firstValue + secondValue;
    }
}

Notice how the parameters passed to the method are integers, the calculator doesn’t accept string values.

What we are saying here is while it’s acceptable for the ViewModel to use strings for storing numbers the domain layer (or business logic if you prefer) does not.

In other words the add method does nothing more than add two numbers together. Validation should be handled elsewhere.

This makes the unit tests for the calculator very easy to write

[TestFixture]
public class When_calculating_numbers
{
    [Test]
    public void Should_be_able_to_add_two_numbers_together()
    {
        // Arrange
        Calculator calculator = new Calculator(); 

        // Act
        var result = calculator.Add(5, 5);

        //Assert
        Assert.That(result, Is.EqualTo(10));
    }
}

The code below shows how the ViewModel could create an instance of the Calculator class and call the Add Method. Notice how I say could and not should. We’ll see why later in the series.

public void Calculate()
{
    Calculator calculator = new Calculator();
    Result = calculator.Add(Convert.ToInt32(FirstValue), Convert.ToInt32(SecondValue)).ToString();
}

So what have we achieved?

As good boy scouts we have ‘left the ViewModel cleaner than we found it’.

By following the single responsibility principle we have created a ViewModel which is a better canvas for other developers to work with.

If you have arrived here from a search engine, this post is part of series about refactoring Silverlight applications. So if you’re thinking why is the calculator class tightly coupled to the ViewModel? Find out how this can be resolved by applying SOLID design principles using MEF in Silverlight and WPF.

Data generation tools aren’t new concept and they come in many different forms. When I first saw Red Gate Sql Data Generator a couple of years ago, I thought to myself it’s a shame you need a database because this would have been great for unit and integration tests.

In this blog post I want to show you how NBuilder can be used when unit testing with .Net objects. The NBuilder assembly can be downloaded here http://code.google.com/p/nbuilder/.

In this blog post we will be using the product and category classes below

public class Product
{
    public Product()
    {
        Categories = new List<Category>();
    }

    public Guid Id { get; set; }
    public string Name { get; set; }
    public int Rating { get; set; }
    public decimal Price { get; set; }
    public bool InStock { get; set; }
    public List<Category> Categories { get; set; }

    public override string ToString()
    {
        return String.Format("Id:{0}, Name:{1}, Rating:{2}, Price:{3}, InStock:{4}, Categories:{5}", Id, Name, Rating, Price, InStock, Categories.Count);
    }
}

public class Category
{
    public string Name { get; set; }
}

NBuilder default values

The product class contains a variety of types. When you run the following code to create 10 products

[Test]
public void Should_Create_Ten_Products()
{
    var products = Builder<Product>.CreateListOfSize(10).Build();
    products.Count().ShouldEqual(10);
}

this is the output

• For strings NBuilder suffixes the index number to the name of the property e.g. Name1
• For numeric values such as int and decimal the default value is the index number
• For guids a hexadecimal range is used
• Boolean values alternate between true and false for each product
• The categories collection is left empty. This would have been null if we didn’t create a new collection in the constructor of the product class

Changing how NBuilder default values are created

I really like how you can customize NBuilder and use your own convention for creating default values.

For example what if we wanted to change how guids are created.

One way to do this is to inherit from the RandomValuePropertyNamer class and override the GetGuid method as shown below.

public class JagsRandomValuePropertyNamer : RandomValuePropertyNamer
{
    protected override Guid GetGuid(System.Reflection.MemberInfo memberInfo)
    {
        return Guid.NewGuid();
    }
}

After setting the default property namer, all guids are created by calling Guid.NewGuid()

[Test]
public void Product_Should_Have_Guid_Assigned()
{
    BuilderSetup.SetDefaultPropertyNamer(new JagsRandomValuePropertyNamer());

    var product = Builder<Product>
        .CreateListOfSize(10)
        .WhereAll()
            .Have(p => p.Id = Guid.NewGuid())
        .Build();

    product[0].Id.ToString().ShouldNotEqual("00000000-0000-0000-0000-000000000001");
}

Using the WhereAll method to set the InStock to always be true

What if we wanted to change the InStock value to true for all the products in the collection. This can be done using the WhereAll method as shown in the code below

[Test]
public void All_Products_Should_Be_In_Stock()
{
    var products = Builder<Product>
        .CreateListOfSize(10)
        .WhereAll()
            .Have(p => p.InStock = true)
        .Build();

    products.All(p => p.InStock).ShouldBeTrue();
}

Using NBuilder to set parts of a collection

There are two ways you can use Nbuilder to set values in parts of a collection. The first is by using the first or last methods like so

[Test]
public void First_Two_Products_Should_Be_In_Stock()
{
    var products = Builder<Product>
        .CreateListOfSize(10)
        .WhereTheFirst(2)
            .Have(p => p.InStock = true)
        .Build();

    products[0].InStock.ShouldBeTrue();
    products[1].InStock.ShouldBeTrue();
}

the other is to use sections

[Test]
public void Mixture_Of_Products_In_Stock_Using_Sections()
{
    var products = Builder<Product>
        .CreateListOfSize(10)
        .WhereSection(0, 1)
            .Have(p => p.InStock = true)
        .WhereSection(2, 9)
            .Have(p => p.InStock = false)
        .Build();

    products[0].InStock.ShouldBeTrue();
    products[2].InStock.ShouldBeFalse();
}

Using the UniqueRandomList to create unique random lists…

So far we haven’t done anything with the category property.

What if you wanted to build a product collection with each product having a random number of categories?

By calling the HaveDoneToThem and the UniqueRandomList methods we can create a set of products with having different categories to one another

[Test]
public void Products_With_Random_Categories()
{
    var categories = Builder<Category>
        .CreateListOfSize(100)
        .Build();

    var products = Builder<Product>
        .CreateListOfSize(10)
        .WhereAll()
        .HaveDoneToThem(p => p.Categories.AddRange(Pick<Category>.UniqueRandomList(2).From(categories)))
        .Build();

    var productCategoryOne = products[0].Categories[0].Name;
    var productCategoryTwo = products[1].Categories[0].Name;

    productCategoryOne.ShouldNotBeTheSameAs(productCategoryTwo);
}

Extending NBuilder with a Lorem Ipsum string generator

One thing I really like about NBuilder is the ability to extend it.

The code below shows how easy it is to have product names randomly using Lorem Ipsum just by creating a extension method like this

public static class StringExtensions
{
    public const string LoremIpsum = "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.";

    public static IOperable<Product> HavingRandomLoremIpsumProductName(this IOperable<Product> operable)
    {
        ((IDeclaration<Product>)operable).ObjectBuilder.With(x => x.Name = LoremIpsum.Substring(0, new Random().Next(446)));
        return operable;
    }
}

this can be used to generate products with random names like this

[Test]
public void Products_With_Random_LoremIpsum_Names()
{
    var products = Builder<Product>
        .CreateListOfSize(10)
        .WhereAll()
            .HavingRandomLoremIpsumProductName()
        .Build();

    var nameOfProductOne = products[0].Name;
    var nameOfProductTwo = products[1].Name;

    nameOfProductOne.ShouldNotBeTheSameAs(nameOfProductTwo);
}

Jag Reehal’s Final Thought on ‘How NBuilder Could Help You Write Better .Net Unit Tests’

I think frameworks like NBehave could really have a big impact on how you go about having to create test data. The fluent interface is fantastic and it’s so easy to customize.

NBuilder contains a lot more features than I have covered in this post so if you like what you’ve seen make sure you check out the NBuilder documentation.

For the future I’m hoping Fluent NHibernate and NBuilder could work together. For example when you define class maps in Fluent NHibernate you can specify the length of string column. If NBuilder could use information like this when generating data that would really be something special.

The Plain Jane Unit Test Assertion

[Test]
public void The_Plain_Jane_Assertion()
{
    const string firstString = "Hello World";
    const string secondString = "Hello World";

    const int smallNumber = 1;
    const int bigNumber = 500;

    // Are Equal
    Assert.AreEqual(firstString, secondString);

    // Greater Than
    Assert.Greater(bigNumber,smallNumber);

    // Less Than
    Assert.Less(smallNumber,bigNumber);
}

This is what most developers will start off using. No problem with the equals assertion it easy enough to read and use.

However when using the greater or less than assertions, it’s not clear if the first argument should be the lower or the higher value as shown in the screen shot below.

This distraction can easily stop your flow.

The More Fluent NUnit Test Assertion

[Test]
public void The_More_Fluent_Nunit_Assertion()
{
    const string firstString = "Hello World";
    const string secondString = "Hello World";

    const int smallNumber = 1;
    const int bigNumber = 500;

    // Are Equal
    Assert.That(firstString, Is.EqualTo(secondString));

    // Greater Than
    Assert.That(bigNumber, Is.GreaterThan(smallNumber));

    // Less Than
    Assert.That(smallNumber, Is.LessThan(bigNumber));
}

The unit test assertions read a lot more fluently, we no longer have to be concerned about the order of arguments.

If you don’t want to use another third party library, this is for you.

The Super Fluent NBehave Spec Assertion

[Test]
public void The_Super_Fluent_NBehave_Spec_Assertion()
{
    const string firstString = "Hello World";
    const string secondString = "Hello World";

    const int smallNumber = 1;
    const int bigNumber = 500;

    // Are Equal
    firstString.ShouldEqual(secondString);

    // Greater Than
    bigNumber.ShouldBeGreaterThan(smallNumber);

    // Less Than
    smallNumber.ShouldBeLessThan(bigNumber);
}

This example uses the NBehave Spec Framework which you can download from the NBehave site. In addition to being very easy to understand, the use of extension methods means there is a lot less noise.

Some developers will be concerned by losing the word ‘Assert’ in the line that does the assertion. If you arrange your tests using the Arrange, Act, Assert pattern this should not be a problem. See the example below.

[Test]
public void The_NBehave_Spec_Assertion_Using_Arrange_Act_Assert()
{
    // Arrange
    const int inputValue = 1;

    // Act
    var result = inputValue + 1;

    // Assert
    result.ShouldBeGreaterThan(inputValue);
}

Traditionally the naming convention most developers use is to append the word ‘Tests’ to the class name as shown below.

public class UserValidation
{
}

[TestFixture]
public class UserValidationTests
{
}

There is absolutely nothing wrong with it, but this can lead to problems because a test class can become unwieldy and difficult to maintain either because it’s too long, testing a lot of different concerns or both.

In some cases it would make more sense to take different approach and adopt an alternative naming convention. Sticking with the example above instead of having tests for validating a user in one class, a new class could be created for each concern. So instead of

using System;
using NUnit.Framework;
using NBehave.Spec.NUnit;

namespace MyApplication.Validation
{
    [TestFixture]
    public class UserValidationTests
    {
        [Test]
        public void Should_Return_False_When_Username_Length_Is_To_Short()
        {
            // Arrange
            UserValidation userValidation = new UserValidation();

            // Act
            bool result = userValidation.IsUsernameValid(string.Empty);

            // Assert
            result.ShouldEqual(false);
        }

        [Test]
        public void Should_Return_False_When_Username_Length_Is_To_Long() { }

        [Test]
        public void Should_Return_False_When_Username_Contains_Invalid_Characters() { }

        [Test]
        public void Should_Return_True_When_Username_Is_Valid() { }

        [Test]
        public void Should_Return_False_When_Password_Length_Is_To_Short() { }

        [Test]
        public void Should_Return_False_When_Password_Length_Is_To_Long() { }

        [Test]
        public void Should_Return_False_When_Password_Is_Just_Numbers()
        {
            // Arrange
            UserValidation userValidation = new UserValidation();

            // Act
            bool result = userValidation.IsPasswordValid("123456");

            // Assert
            result.ShouldEqual(false);
        }

        [Test]
        public void Should_Return_False_When_Password_Is_Just_Alphabetical_Characters() { }

        [Test]
        public void Should_Return_False_When_Password_Contains_Invalid_Characters() { }

        [Test]
        public void Should_Return_True_When_Password_Is_Valid() { }
    }
}

we create two test classes

using System;
using NUnit.Framework;
using NBehave.Spec.NUnit;

namespace MyApplication.Validation
{
    [TestFixture]
    public class When_Validating_A_Users_Username
    {
        [Test]
        public void Should_Return_False_When_Username_Length_Is_To_Short()
        {
            // Arrange
            UserValidation userValidation = new UserValidation();

            // Act
            bool result = userValidation.IsUsernameValid(string.Empty);

            // Assert
            result.ShouldEqual(false);
        }

        [Test]
        public void Should_Return_False_When_Username_Length_Is_To_Long() { }

        [Test]
        public void Should_Return_False_When_Username_Contains_Invalid_Characters() { }

        [Test]
        public void Should_Return_True_When_Username_Is_Valid() { }
    }

    [TestFixture]
    public class When_Validating_A_Users_Password
    {
        [Test]
        public void Should_Return_False_When_Password_Length_Is_To_Short() { }

        [Test]
        public void Should_Return_False_When_Password_Length_Is_To_Long() { }

        [Test]
        public void Should_Return_False_When_Password_Is_Just_Numbers()
        {
            // Arrange
            UserValidation userValidation = new UserValidation();

            // Act
            bool result = userValidation.IsPasswordValid("123456");

            // Assert
            result.ShouldEqual(false);
        }

        [Test]
        public void Should_Return_False_When_Password_Is_Just_Alphabetical_Characters() { }

        [Test]
        public void Should_Return_False_When_Password_Contains_Invalid_Characters() { }

        [Test]
        public void Should_Return_True_When_Password_Is_Valid() { }
    }
}

I think this behavior driven development type naming convention will help focus on the problem you are solving and nothing more. This is very useful when doing test driven development.

When I first saw tests written like this my first thought was how am I going to find the all the tests for User Validation because they are no longer in a single class? If this is a problem for you think about using namespaces, folders or test attributes to organise your tests. Don’t forget if you use tools like ReSharper help you find where a class is being used very easily.

Remember this is about renaming your tests classes and not your methods. So even if you follow the MethodName_StateUnderTest_ExpectedBehavior pattern for test methods this could still work.

In this post we will go through how to create the game using ASP.NET MVC, jQuery and jQuery UI.

The screenshot below shows the game running.

The code used for creating the game in ASP.NET MVC, jQuery and jQuery UI can be downloaded here.

Getting Started

Instead of three animals used in the demo, the game now contains fourteen. I’ve created a repository which returns the animals. To keep things simple there’s no database here, instead the animals are hard coded.

using System.Linq;
using GameUsingAspNetMVCandJQueryUI.Core.Models;

namespace GameUsingAspNetMVCandJQueryUI.Core.Repository
{
    public class AnimalsRepository : IAnimalsRepository
    {
        public IQueryable<Animal> GetAll()
        {
            return new Animal[]
                       {
                           new Animal(){Name = "Cow"},
                           new Animal(){Name = "Cat"},
                           new Animal(){Name = "Chicken"},
                           new Animal(){Name = "Dog"},
                           new Animal(){Name = "Elephant"},
                           new Animal(){Name = "Giraffe"},
                           new Animal(){Name = "Hippo"},
                           new Animal(){Name = "Lion"},
                           new Animal(){Name = "Monkey"},
                           new Animal(){Name = "Mouse"},
                           new Animal(){Name = "Owl"},
                           new Animal(){Name = "Penguin"},
                           new Animal(){Name = "Pig"},
                           new Animal(){Name = "Sheep"},
                       }
                .AsQueryable();
        }
    }
}

Command Query Separation

One of the features I have added is to ensure a correct answer for the current game could not be the correct answer in the next. As the repository class was responsible for getting animals, having it contain any logic would violate good design principles.

So the logic goes into the service layer which returns a data transfer object for animals and the correct answer.

using System.Linq;
using GameUsingAspNetMVCandJQueryUI.Core.ExtensionMethods;
using GameUsingAspNetMVCandJQueryUI.Core.Models;
using GameUsingAspNetMVCandJQueryUI.Core.Repository;

namespace GameUsingAspNetMVCandJQueryUI.Core.Service
{
    public class AnimalsService : IAnimalsService
    {
        private readonly IAnimalsRepository _animalsRepository;

        public AnimalsService(IAnimalsRepository animalsRepository)
        {
            _animalsRepository = animalsRepository;
        }

        public AnimalsDto GetAnimalsForGameWithCorrectAnswer(int numberOfAnimals, string previousAnimal)
        {
            AnimalsDto animalsDto = new AnimalsDto();
            animalsDto.Animals = _animalsRepository
                .GetAll()
                .Where(a => a.Name != previousAnimal)
                .Shuffle()
                .Take(numberOfAnimals);

            animalsDto.CorrectAnswer = animalsDto.Animals.Shuffle().First().Name;

            return animalsDto;
        }
    }
}

This also makes testing easier because the tests can focus on making sure the service is doing what it should like this

using System;
using System.Linq;
using GameUsingAspNetMVCandJQueryUI.Core.Models;
using GameUsingAspNetMVCandJQueryUI.Core.Repository;
using GameUsingAspNetMVCandJQueryUI.Core.Service;
using NBehave.Spec.NUnit;
using NUnit.Framework;
using Rhino.Mocks;

namespace GameUsingAspNetMVCandJQueryUI.Tests
{
    [TestFixture]
    public class AnimalsServiceTests
    {
        private IAnimalsService _animalsService;
        private IAnimalsRepository _animalsRepository;

        private readonly IQueryable<Animal> _animalsStub = new Animal[]
                           {
                               new Animal(){Name = "Cow"},
                               new Animal(){Name = "Pig"},
                               new Animal(){Name = "Sheep"},
                           }.AsQueryable();

        [SetUp]
        public void SetUp()
        {
            _animalsRepository = MockRepository.GenerateStub<IAnimalsRepository>();
            _animalsService = new AnimalsService(_animalsRepository);
        }

        [Test]
        public void Should_Exclude_Previous_Animal_When_Previous_Animal_Is_Passed_In()
        {
            // Arrange
            _animalsRepository.Stub(a => a.GetAll()).Return(_animalsStub);
            var previousAnimal = _animalsStub.First();

            // Act
            var result = _animalsService.GetAnimalsForGameWithCorrectAnswer(3, previousAnimal.Name);

            // Assert
            result.Animals.Count(a => a.Name == previousAnimal.Name).ShouldEqual(0);
        }

        [Test]
        public void Should_Return_All_Animals_When_No_Previous_Animal_Is_Passed_In()
        {
            // Arrange
            _animalsRepository.Stub(a => a.GetAll()).Return(_animalsStub);
            string previousAnimal = String.Empty;

            // Act
            var result = _animalsService.GetAnimalsForGameWithCorrectAnswer(3, previousAnimal);

            // Assert
            result..Animals.Count().ShouldEqual(3);
        }

        [Test]
        public void Should_Return_All_Animals_When_No_Previous_Animal_Is_Null()
        {
            // Arrange
            _animalsRepository.Stub(a => a.GetAll()).Return(_animalsStub);
            string previousAnimal = null;

            // Act
            var result = _animalsService.GetAnimalsForGameWithCorrectAnswer(3, previousAnimal);

            // Assert
            result.Animals.Count().ShouldEqual(3);
        }

        [Test]
        public void Correct_Answer_Should_Not_Be_Empty()
        {
            // Arrange
            _animalsRepository.Stub(a => a.GetAll()).Return(_animalsStub);            

            // Act
            var result = _animalsService.GetAnimalsForGameWithCorrectAnswer(3, null);

            // Assert
            result.CorrectAnswer.ShouldNotBeEmpty();
        }
    }
}

The LINQ Shuffle

Even though we have removed the previous answer, if the animals were returned as they are the answer would just be the next one in the list. So to keep the game exciting, a shuffle extension method is used to shuffle the answers.

using System;
using System.Collections.Generic;
using System.Linq;

namespace GameUsingAspNetMVCandJQueryUI
{
    public static class GameExtensions
    {
        public static IEnumerable<T> Shuffle<T>(this IEnumerable<T> items)
        {
            var rnd = new Random();
            IEnumerable<int> numbers = Enumerable.Range(0, items.Count()).OrderBy(r => rnd.Next());
            var randomItems = new List<T>();
            foreach (int number in numbers)
            {
                randomItems.Add(items.Skip(number).First());
            }
            return randomItems;
        }
    }
}

This can be unit tested as shown below

using System.Collections.Generic;
using System.Linq;
using GameUsingAspNetMVCandJQueryUI.Core.Models;
using NUnit.Framework;

namespace GameUsingAspNetMVCandJQueryUI.Tests
{
    [TestFixture]
    public class GameExtensionsTests
    {
        [Test]
        public void Can_Shuffle_Animals()
        {
            List<Animal> animals = new List<Animal>()
                           {
                               new Animal(){Name = "Cow"},
                               new Animal(){Name = "Pig"},
                               new Animal(){Name = "Sheep"},
                           };
            IList<Animal> result = animals.Shuffle().ToList();
            Assert.IsFalse(
                animals[0].Equals(result[0]) &&
                animals[1].Equals(result[1]) &&
                animals[2].Equals(result[2]),
                "Animals should have been shuffled");
        }
    }
}

What happens when a player opens the game in their browser?

When the page loads an Ajax call is made using jQuery to an Asp.Net MVC action method which returns a JsonResult.

   $.getJSON("/Game/GetAnimals",
            { numberOfAnimals: numberOfItemsToGet, previousAnimal: correctAnswer.text() },
            function(data) {
                addItems(data);
                $("#droppable").droppable(droppableOptions);
                assignDraggables();
                hideItemsForLevel();
                setUpSlider();
                setTimeout(function() {
                    instructions.text(instructionsText);
                    items.show();
                }, 1000);
            });

Two parameters are passed to the action method, one for the previous answer and the other for the number of animals required. The reason for this is because we don’t want to transfer more data over the wire than required, why return fourteen animals when only six are required?

The ‘GetAnimals’ Asp.Net MVC action method shown below serializes the view model returned by the service layer into JSON.

using System.Web.Mvc;
using GameUsingAspNetMVCandJQueryUI.Core.Service;

namespace GameUsingAspNetMVCandJQueryUI.Controllers
{
    [HandleError]
    public class GameController : Controller
    {
        private readonly IAnimalsService _animalsService;

        public GameController(IAnimalsService animalsService)
        {
            _animalsService = animalsService;
        }

        public ActionResult Index()
        {
            return View("Index");
        }

        [OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]
        public JsonResult GetAnimals(int numberOfAnimals, string previousAnimal)
        {
            return Json(_animalsService.GetAnimalsForGameWithCorrectAnswer(numberOfAnimals,previousAnimal));
        }
    }
}

Notice how I have to be explicit about how I do NOT want the JsonResult to be cached. If you don’t add this Internet Explorer will cache the result and you will get the same animals.

Using the jQuery and jQuery UI in the ASP.NET MVC View

The JavaScript used the demo was good enough to perform the dragging and dropping of pictures so the good news is we can use it again here.

An additional feature I have added is to allow the player to change the difficulty of the game by choosing how many animals are shown on the screen.

To do this I used the jQuery UI slider and jQuery fade functionality. The reason I used fade rather show/hide in jQuery was because I didn’t want the animals to move position when a user changed the difficulty as this would have resulted in a poor user experience by confusing the player.

Currently the message which tells the player if they have selected an incorrect answer is shown when the user stops dragging the animal. This is a problem because if the user drags a correct animal but doesn’t drop it on the droppable a message isn’t shown. If I find a fix for this I’ll update the code and this post.

Jag Reehal’s Final Thought on ‘Creating the animals game using Asp.Net MVC, jQuery and jQueryUI’

I’ve been using jQuery for a while now and I still love it.

The jQuery UI library is very good and the jQuery UI team have done a fantastic job creating demos and documentation.

I really like how you can create your own custom javascript file which only contains the features you require from the library.

No doubt some people will question why the service is returning a data transfer object. I could have returned a collection of animals to the ASP.NET MVC controller and have it create an object to pass to the view. The reason I didn’t do this is because I know the data transfer object will be used by another user interface layer (Silverlight) and because this would have bloated the controller and that’s not good. A best practice for ASP.NET MVC is to have skinny controllers.

The images for the animals used in the game are from http://www.openclipart.org.

Because my latest changes were not being picked up, I always had to build my solution first and then run the unit tests.

Not anymore.

Today a colleague showed me this ‘Build Settings’ option

Selecting ‘Always Build’ makes sure the latest changes (even to config files) are used when running unit tests. The default is ‘Automatic’ as shown above.

Just be aware of the size of your solution will have an impact on how long the tests will take to run.