ASP.NET MVC template for MbUnit tests needs to be fixed.

There’re so many new technologies and tools appearing all the time that it’s impossible to keep up. 

First time I looked at ASP.NET MVC framework was more than a year ago when Microsoft just released the first Beta.  I really liked the new web framework for decoupling and testability. However, because I didn’t have any project where I could use it I left it alonge and started playing with some other toys like WPF and Silverlight.  Now my company is starting developing using ASP.NET MVC framework and it’s time for me get familiar with it again.

So I updated my ASP.NET MVC Beta with RC1.  As a next step I created a sample site using ASP.NET MVC Web Application template.

When I was asked if I want to create unit tests, I couldn’t say NO.  As a unit test framework I chose MbUnit v3.

After all the default files were generated by the template, I compiled the solution before making any modifications.  I was surprised when the solution failed to compile.   I got the following errors:

As soon as I look at these errors I realized that I’m missing the following using statements:

using System.Web.Mvc;

using MyNamespace.Controllers;

After adding the missing statements, the solution compiled without any problems.

It’s not a hard problem for a developer to correct but I hope that ASP.NET MVC team will fix the template before they ship the final “1.0″ release.

Gallio and MbUnit v3.0.4 is out

Yesterday Jeff Brown released the latest Gallio and MbUnit.

To find out more about new features read the announcement by Jeff.

You can download it from http://www.gallio.org/Downloads.aspx.

Comparing Reference Types in Unit Tests.

If you’ve done some unit testing, you’re familiar with Assert.AreEqual method.  Have you try to compare two objects that have the same value(s) but the AreEqual method tells you that they are not equal?  For example let assume that we have a class Point:

   1: private class Point

   2: {

   3:   private int _x;

   4:   private int _y;

   5:  

   6:   public Point(int x, int y)

   7:   {

   8:     _x = x;

   9:     _y = y;

  10:   }

  11: }

And we test for the constructor:

   1: [Test]

   2: public void Point_constructor_test()

   3: {

   4:   Point point = new Point(2, 3);

   5:   Assert.AreEqual(point, new Point(2, 3));

   6: }

When I run this test using MbUnit, the assertion fails.  The reason it fails because Point is a reference type.     Actually what is getting compared is objects references (not objects values) and of course they have different references.

One way we could fix it is to make Point a Value Type by replacing class with struct.

   1: private struct Point

   2: {

   3:   private int _x;

   4:   private int _y;

   5:   

   6:   public Point(int x, int y)

   7:   {

   8:     _x = x;

   9:     _y = y;

  10:   }

  11: }

This definitely resolves the issue.

Another thing we could do is implement IEquatable<T> interface:

   1: private class Point : IEquatable<Point>

   2: {

   3:   private int _x;

   4:   private int _y;

   5:  

   6:   public Point(int x, int y)

   7:   {

   8:     _x = x;

   9:     _y = y;

  10:   }

  11:  

  12:   public bool Equals(Point other)

  13:   {

  14:     return (_x == other._x) && (_y == other._y);

  15:   }

  16: }

[Updated] However, MbUnit test still will fail because deep inside MbUnit’s AreEqual calls object.Equal(object).  In order for AreEqual to succeed in this case, it needs to call generic version of AreEqual.  Something like this:

   1: private static bool AreEqual<T>(T expected, T actual)

   2: {

   3:   if (expected is IEquatable<T> )

   4:     return ((IEquatable<T>)expected).Equals(actual);

   5:   return expected.Equals(actual);

   6: }

It means we need to modify our test little bit. Instead of AreEquals method we can use IsTrue one.

   1: [Test]

   2: public void Point_constructor_test()

   3: {

   4:   Point point = new Point(2, 3);

   5:   Assert.IsTrue(point.Equals(new Point(2, 3)));

   6: }

In software development the same problem can be solved many different ways.  I assume that most common solution is going to be comparing some public properties in the object instead of the whole object.

Let assume assume that our Point class has public properties X and Y.  Here’s an example how my test would look:

   1: [Test]

   2: public void Point_constructor_test()

   3: {

   4:   Point point1 = new Point(2, 3);

   5:   Point point2 = new Point(2, 3);

   6:   Assert.AreEqual(point1.X, point2.X);

   7:   Assert.AreEqual(point1.Y, point2.Y);

   8: }

Mock DataTable

Today I had to work with some legacy code.  It was originally written in Delphi and then converted line by line to C#.  Before changing anything in the code I decided to create unit tests and make sure that I have 100% coverage.

One of the thing I had to do in my unit test is to mock DataTable.  Here are the steps I made during mocking.

1. Create needed columns in a DataTable.
2. Create a new DataRow.
3. Assign values to the row.
4. Finally add the row to the DataTable.

Repeat steps 2- 4 for each row you want to add to your DataTable.

Here’s the example:

   1: [Test]

   2: public void HolidayTest()

   3: {

   4:   MockRepository mocks = new MockRepository();

   5:   ICompanyDAL dalMock = mocks.CreateMock<ICompanyDAL>();

   6:   // Create DataTable

   7:   DataTable fakeHolidays = new DataTable();

   8:   // 1. Add Columns

   9:   fakeHolidays.Columns.Add("Holiday", typeof (DateTime));

  10:   fakeHolidays.Columns.Add("Name", typeof(string));

  11:   // 2. Create new DataRow

  12:   DataRow dayRow = fakeHolidays.NewRow();

  13:   // 3. Assign values to the row

  14:   dayRow["Holiday"] = DateTime.Parse("07/04/2008");

  15:   dayRow["Name"] = "Independence Day";

  16:   // 4. Add the row to the DataTable

  17:   fakeHolidays.Rows.Add(dayRow);

  18:   _pgDate.CompanyDal = dalMock;

  19:   using (mocks.Record())

  20:   {

  21:     Expect.Call(dalMock.GetHolidays()).Return(fakeHolidays);

  22:   }

  23:   using (mocks.Playback())

  24:   {

  25:     DataTable holidays = _pgDate.Holidays;

  26:     Assert.GreaterThan(holidays.Rows.Count, 0);

  27:   }

  28: }

I used Rhino.Mocks as my mocking framework in the example above.

How To: Create a ReSharper File Template.

ReSharper is a wonderful tool that makes writing code much easier.  One of the features of this tool is ability to create templates.  With ReSharper you can create Live, Surround With, and File Template.  In this post I want to share with you how to create a File Template for MbUnit Test Fixture.

After completion of this tutorial, you’ll be able to create an MbUnit Fixture by right clicking the test project and adding the test fixture.

 

 

Step 1: Open ReSharper – Options dialog.

Start Visual Studio and from menu bar select ReSharper – Options (you also can get there by pressing Alt-R + O).

Step 2: Create a new template.

• In the left panel select File Templates under Templates section.
• Then select User Templates in Available templates.
• In this sample we’re going to create C# template, so select Class (C#) in Quick access list (it should be the first item in the list).
• Last click on Create Template icon to see Edit Template dialog box.

Step 3: Create and save MbUnit Test Fixture template.

• In Name text box enter MbUnit Fixture.  It’s a name that will appear in the menu when you add a new test fixture.
• In File name prefix text box enter MbTest.  It’s going to be a suggestion for your test file / class.

 

Next click on everywhere link next to the word Available to see the Template Options dialog box.  Select Only in projects for language radio button and chose C# projects including ASP.NET C#projects) from the drop-down control. Extension for created files leave as cs.

Now we are ready to create actual template.

Enter the code below into Template text.

   1: using MbUnit.Framework;

   2:  

   3: namespace $NAMESPACE$

   4: {

   5:    [TestFixture]

   6:    [FixtureCategory("$CATEGORY$")]

   7:    [Author("Vadim Kreynin", "Vadim@kreynin.com")]

   8:    public class $CLASS$ {$END$}

   9: }

I’m sure that you noticed $NAMESPACE$, $CATEGORY$, and $CLASS$.  These three are ReSharper variables.  You declare a variable by surrounding a word with $ sign.

The reason we created variables because we want to do something with them.

ReSharper has automatically created entries for our variables that looks like this:

Click on Choose macro link and choose following options in Choose Macro dialog box.

Variable	Available macro
$NAMESPACE$	Default namespace for current file
$CATEGORY$	Constant value
$CLASS$	Current file name without extension

Uncheck Editable Occurrence check box for NAMESPACE variable.

You can see that CATEGORY variable has a red link Constant value.  Click on it and enter Category in String value text box of Choose Parameter Value dialog box.

You’re done!  Click on OK button of Edit Template dialog box that should look like this:

Now you can start using this template.

Next time I’ll show how to create a Live Template for tests, test SetUp(s) and TearDown(s).

 

Explaining MbUnit GUI tree.

When the first time I looked at MbUnit GUI tool, I was overwhelmed with complex tree structure. The root has five branches: Authors, Categories, Importances, Namespaces, and TestsOns. I was able relate to Namespaces and Categories; I’ve seen something similar in NUnit. But what for are other three branches. Well, MbUnit GUI shows the branches in alphabetical order. There for I’ll try explain the branches in the same order. I’ll start with Authors and end with TestsOns.

Authors

It’s pretty clear that if you want to claim ownership of the test fixture you need to put it inside the Authors. It’s not hard to do. What you need to do is to use Author attribute on your fixture. Author attribute has three overloads:

   1: [TestFixture]

   2: [Author("Vadim")]

   3: public class MyTest {}

 

   1: [Author("Vadim", "vadim@domain.com")]

   2: [Author("Vadim", "vadim@domain.com", http://vkreynin.wordpress.com/)]

Before we added Author(“Vadim”), we had “Anonymous” leaf inside the Authors branch. “Anonymous” always will have test fixtures that don’t have an Author attribute. I believe it’s a good practice to use this attribute on big projects. However, instead of a person name I would use a team name. The reason I think it should be a team name because a developer can switch a team, find a better job or win a lottery and leave the team. A team is responsible for the part of the project they are working on and there for they also should be responsible for the tests. Also a team probably would like to run all the tests related to the team before checking in the code.

Categories

Categories branch is obviously for categorized test fixtures. You can assign multiple categories to a test fixture. Here how you do it using FixtureCategory attribute.

   1: [TestFixture]

   2: [FixtureCategory("Demo")]

   3: [FixtureCategory("WebPayroll")]

All the test fixtures that don’t have a category assigned can be found in Categories/Misc branch.

Importances

This branch specifies the importance of the test fixture. MbUnit Framework defines five different types of test fixture importance.

• Critical
• Default
• NoOneReallyCaresAbout
• Serious
• Severe

Importance can be defined by Importance attribute.

   1: [TestFixture]

   2: [Importance(TestImportance.Severe)]

The test fixtures that don’t have importance can be found in Default importance. To be honest I didn’t find it very useful yet. Let me know how you use this attribute.

Namespaces

I don’t think that I need to explain this. Anybody who develops using .NET know what Namespace is.

TestsOns

For some reason this one took me the longest to figure out. Using TestsOn attribute you can specify what class the test fixture is testing.

   1: [TestFixture]

   2: [TestsOn(typeof(Employee))]

In the example above we are saying that the test fixture is testing Employee class. All the test fixtures that don’t use TestsOn attribute can be found in Unknown branch.

MbUnit: Testing Internal classes

Jonathan ‘Peli’ de Halleux wrote an article ‘Pex It: Testing Internal classes‘.   I just want to let the world know that you also can test non-public classes with MbUnit.  You need  version 2.4.1.220 or higher to use this feature.

In example bellow we test IsWhite(Char) method of System.Number class inside mscorlib assembly.  Using Reflector you can see that Number is an internal class and IsWhite is a private method of this class.  We can test this method event if we don’t have the source code.

private static readonly string MSCorLibAssembly = 

    Environment.GetEnvironmentVariable("SystemRoot")

    + @"\Microsoft.NET\Framework\v2.0.50727\mscorlib.dll";

[Test]

public void InternalClassTest()

{

    string className = "System.Number";

    object obj = 

        Reflector.CreateInstance(MSCorLibAssembly, className);

    Assert.IsNotNull(obj);

    Assert.AreEqual(true,

        Reflector.InvokeMethod(

            AccessModifier.Default, obj, "IsWhite", ' '));

    Assert.AreEqual(false,

        Reflector.InvokeMethod(

            AccessModifier.Default, obj, "IsWhite", 'V'));

}

The Number class has only default constructor.  It means we don’t need to send parameters when creating an instance.

Let’s look at another example.  This time we’re going to write test for the Key and Value properties of System.Collections.KeyValuePairs class.  This class is also internal.  If you don’t believe me, use Reflector.  KeyValuePairs class has only one constructor that takes two Object parameters.

[Test]

public void InternalClassNonDefaultConstructor()

{

    string className = "System.Collections.KeyValuePairs";

    object obj = 

        Reflector.CreateInstance(MSCorLibAssembly, className, 1, 'A');

    Assert.IsNotNull(obj);

    Assert.AreEqual(1, Reflector.GetProperty(obj, "Key"));

    Assert.AreEqual('A', Reflector.GetProperty(obj, "Value"));

}

 Happy Testing :)

Better alternative to unit test data.

Roy Osherove created two posts about how to create test data for unit tests.  First one talks about encoding test data as part of your test xml comments and the second one is how to do the same using XtUnit custom attributes.  It’s much easier and requires less typing if you use MbUnit RowTest attribute.

        [RowTest]
        [Row("Select * from categories")]
        public void UseMbUnitRowTestAttribute(string actual)
        {
            string expected = "Select * from categories";
            Assert.AreEqual(expected, actual);
        }

RowTest enhancements in MbUnit 2.4 RTM

One of MbUnit features that made me switch from NUnit is ability to send parameters in tests with RowTest attribute. If you’ve been using this feature, it’s time to get excited.  Because with release of new version, MbUnit has more RowTest improvements.  Julian implemented these enhancements and created an excellent post for you to read.

Addition to Julian Hidalgo blog on TestSequence attribute.

MbUnit contributor, Julian Hidalgo, blogs about using TestSequence attribute. He points out the typical mistake people have when they try to use this attribute for the first time. When I tried to use it for the first time, I also used TestFixture attribute instead of ProcessTestFixture one.

Julian did a good job of demonstrating how to use it. I would like to add that when you put your tests in ProcessTestFixutre, MbUnit will combine all your tests into one big test. The name of the big test will be all your test names separated by a period in the order specified by TestSequence attribute. For instance, if you have a fixture like the one bellow (borrowed from Julian’s blog), your big test name will be SequenceAttributeTest.Test1.Test2.

    [ProcessTestFixture]

    public class SequenceAttributeTest

    {

        private int i = 0;

        [Test]

        [TestSequence(2)]

        public void Test2()

        {

            i += 1;

            Assert.AreEqual(i, 2);

        }

        [Test]

        [TestSequence(1)]

        public void Test1()

        {

            i += 1;

            Assert.AreEqual(i, 1);

        }

    }

Another thing I’d like to mention is that if one of the tests fails, the execution stops. It means that no test will be executed after failed test.  If in example above Test1 fails, Test2 will not be run.

Unfortunately, you cannot use RowTest in ProcessTestFixutre.