Archive

Posts Tagged ‘Unit Testing’

Mocking Sitecore with Microsoft Fakes part 2

10/04/2013 6 comments

In this post I will continue where part 1 left, you can find part 1 here. This post will be rich with examples on how to use Microsoft fakes, now included in VS 2012 Premium, to mock out different parts of Sitecore. All the Examples  has been chosen, because I think they include some of the most used functions or interactions with Sitecore. They are all really small example, and you can off course combine them as you like.

 

To start with lets take a look at the Sitecore Item and some of the properties not covered in part 1.

 [TestMethod]
 public void Mocking_ItemProperties()
 {
    using (ShimsContext.Create())
    {
      ID expectedId = ID.NewID;
      ID expectedTemplateId = ID.NewID;
      string expectedName = "ShimItem";
      string expectedDisplayName = "ShimItem";

      //Setting some of the most used properties on a Item
      Item item = new ShimItem()
      {
         IDGet = () => expectedId,
         NameGet = () => expectedName,
         DisplayNameGet = () => expectedDisplayName,
         TemplateIDGet = () => expectedTemplateId
      };

      Assert.AreSame(expectedId, item.ID);
      Assert.AreSame(expectedTemplateId, item.TemplateID);
      Assert.AreSame(expectedName, item.Name);
     Assert.AreSame(expectedDisplayName, item.DisplayName);
   }

 }

 [TestMethod]
 public void Mocking_Item_Children()
 {
    using (ShimsContext.Create())
    {
      //Setup an valid item list you can add more item properties if you like
      List<Item> childList = new List<Item>();
      childList.Add(new ShimItem() { NameGet = () => "1" });
      childList.Add(new ShimItem() { NameGet = () => "2" });
      childList.Add(new ShimItem() { NameGet = () => "3" });
      childList.Add(new ShimItem() { NameGet = () => "4" });
      childList.Add(new ShimItem() { NameGet = () => "5" });

      ChildList children = new ShimChildList()
      {
        GetEnumerator = () => childList.GetEnumerator(),
        CountGet = () => childList.Count
      };

      Item item = new ShimItem()
      {
        ChildrenGet = () => children
      };

      Assert.AreEqual(item.Children.Count,childList.Count);
      foreach (Item child in item.Children)
      {
        Assert.IsFalse(string.IsNullOrEmpty(child.Name));
      }
    }
 }

With that covered lets see some examples of how to mock the Sitecore Database.

[TestMethod]
  public void Mocking_Database_GetName()
  {
     using (ShimsContext.Create())
     {
       string expectedName = "web";
       Database database = new ShimDatabase()
        {
NameGet = () => expectedName
        };
        Assert.AreEqual(expectedName, database.Name);
    }
}

   [TestMethod]
   public void Mocking_Database_GetRootITem()
   {
     using (ShimsContext.Create())
     {
       string expectedItemName = "Shim";
       Item item = new ShimItem()
         {
          NameGet = () => expectedItemName
         };
       Database database = new ShimDatabase()
       {
         GetRootItem = () => item
       };

       Item rootItem = database.GetRootItem();

      Assert.AreEqual(expectedItemName, rootItem.Name);
    }
  }

Finally lets combine the two above and try to mock the Static context of Sitecore. How often have you wrote Sitecore.Context.Item, Sitecore.Context.Site or Sitecore.Context.Database.


 [TestMethod]
 public void Mocking_Context_Item()
 {
    using (ShimsContext.Create())
    {
      string expectedName = "CurrentItem";
      Item item = new ShimItem()
       {
          NameGet =()=> expectedName
       };

     ShimContext.ItemGet = () => item;

     Item contextItem = Sitecore.Context.Item;

     Assert.AreEqual(expectedName, contextItem.Name);
   }
 }

 [TestMethod]
 public void Mocking_Context_Database()
 {
   using (ShimsContext.Create())
   {
     string expectedDatabaseName = "web";
     Database database = new ShimDatabase()
       {
        NameGet = () => expectedDatabaseName
       };

    ShimContext.DatabaseGet = () => database;

    Database currentDatabase = Sitecore.Context.Database;

    Assert.AreEqual(expectedDatabaseName, currentDatabase.Name);
  }
 }

 [TestMethod]
 public void Mocking_Context_Site()
 {
   using (ShimsContext.Create())
   {
     string expectedName = "CurrentItem";
     Item item = new ShimItem()
     {
       NameGet =()=> expectedName,
     };

    string expectedDatabaseName = "web";
    Database database = new ShimDatabase()
     {
      NameGet = () => expectedDatabaseName
     };

    SiteContext siteContext = new ShimSiteContext()
     {
       StartItemGet = () => item.Name,
       DatabaseGet = () => database
     };

    ShimContext.SiteGet = () => siteContext;
    SiteContext context = Sitecore.Context.Site;

    Assert.AreEqual(expectedDatabaseName, context.Database.Name);
    Assert.AreEqual(expectedName, context.StartItem);
  }

}

With that i think we pretty much covered some of the most used properties and method from Sitecore, without creating wrappers. If there are some missed examples of examples you would like to see please say so.

Otherwise stay tuned for Part 3.

Mocking Sitecore with Microsoft Fakes part 1

08/04/2013 12 comments

This post have been  in making for a while or since the Visual Studio 2012 Update 2 was announced. Especially since the update added Microsoft Fakes to VS 2012 Premium. With Fakes it is now possible to mock  Static methods and otherwise unmockable class’ for example DataTime.Now or a Sitecore Item. So now finally it is possible to do unit testing with Sitecore or if you like TDD. I know that this has been possible for a while if you used Glass Mapper og had access to a Typemock license.

This post is the first in a small series, on how to mock Sitecore out using Microsoft Fakes, and to begin with, I will have a look and extracting data from a Sitecore Item.

The two ways to get data from item i will cover here is either accessing a field through the field collection using item.Field[name of your field] or by the indexing found on the BaseItem which Item derives from like this item[name of your field].

The two code snippets below is used to run my test against one uses Field[] the other Item[]

 

public class CodeSnippet
{
   public static ID MY_TEXT_FIELD = new ID("{dc321650-5b1d-479a-ae81-c04d6585140d}");
   public static ID MY_CHECKBOX_FIELD = new ID("{a007c875-5192-4068-864d-523ffaa0b4ca}");
   public static string MISSING_TEXT = "MISSING TEXT";

   public string RunWithDataFromFieldCollection(Item item)
   {

      CheckboxField checkboxField = new CheckboxField(item.Fields[MY_CHECKBOX_FIELD]);
      if (checkboxField.Checked)
      {
        TextField textField = new TextField(item.Fields[MY_TEXT_FIELD]);
        string textValue = textField.Value;
        if (!string.IsNullOrEmpty(textValue))
          return textValue;
        return MISSING_TEXT;
      }
      return string.Empty;
  }

  public string RunWithDataFromBaseCustomItemIndex(Item item)
  {
    bool isChecked = item[MY_CHECKBOX_FIELD] == "1";
    if (isChecked)
    {
      string textValue = item[MY_TEXT_FIELD];
      if (!string.IsNullOrEmpty(textValue))
       return textValue;
      return MISSING_TEXT;
    }
    return string.Empty;
  }
}

First we look at the code that uses the Field[], This example is much like using the TestItem if used in earlier post found here, or at least the setup is. You need to setup a fieldcollection and ensure that the fields used exists in the collection.

 [TestClass]
 public class TestFieldAccess
 {
    private CodeSnippet _codeSnippet;

   [TestInitialize]
   public void Initialize()
   {
     _codeSnippet = new CodeSnippet();
   }

   [TestCleanup]
   public void CleanUp()
   {
     _codeSnippet = null;
   }

   [TestMethod]
   public void Run_WithCheckboxFieldNotChecked_ShouldReturnEmptyString()
   {
     using (ShimsContext.Create())
     {
       Field checkBoxField = new ShimField()
       {
         IDGet = () => CodeSnippet.MY_CHECKBOX_FIELD,
         ValueGet = () => "0"
       };
       FieldCollection fieldCollection = new ShimFieldCollection()
       {
         ItemGetID = id => checkBoxField
       };

       Item itemStub = new ShimItem() { FieldsGet = () => fieldCollection};
       string actualText = _codeSnippet.RunWithDataFromFieldCollection(itemStub);

       Assert.AreSame(string.Empty, actualText);
    }
  }

  [TestMethod]
  public void Run_WithCheckboxFieldCheckedButNotTextInTextField_ShouldReturnMissingText()
  {

   using (ShimsContext.Create())
   {
     Field checkBoxField = new ShimField()
     {
       IDGet = () => CodeSnippet.MY_CHECKBOX_FIELD,
       ValueGet = () => "1"
     };
     Field textField = new ShimField()
     {
      IDGet = () => CodeSnippet.MY_TEXT_FIELD,
      ValueGet = () =>string.Empty
     };
     FieldCollection fieldCollection = new ShimFieldCollection()
     {
      ItemGetID = id => id==CodeSnippet.MY_CHECKBOX_FIELD ?checkBoxField : id == CodeSnippet.MY_TEXT_FIELD ? textField : null
     };

     Item itemStub = new ShimItem() { FieldsGet = () => fieldCollection };
     string actualText = _codeSnippet.RunWithDataFromFieldCollection(itemStub);

     Assert.AreSame(CodeSnippet.MISSING_TEXT, actualText);
    }
   }

  [TestMethod]
  public void Run_WithCheckboxFieldCheckedButNotTextInTextField_ShouldReturnActualTextFromTextField()
  {
    using (ShimsContext.Create())
    {
     string expectedText = " Should return this string";
     Field checkBoxField = new ShimField()
     {
       IDGet = () => CodeSnippet.MY_CHECKBOX_FIELD,
       ValueGet = () => "1"
     };
     Field textField = new ShimField()
     {
       IDGet = () => CodeSnippet.MY_TEXT_FIELD,
       ValueGet = () => expectedText
     };
    FieldCollection fieldCollection = new ShimFieldCollection()
    {
      ItemGetID = id => id == CodeSnippet.MY_CHECKBOX_FIELD ? checkBoxField : id == CodeSnippet.MY_TEXT_FIELD ? textField : null
    };

    Item itemStub = new ShimItem() { FieldsGet = () => fieldCollection };

     string actualText = _codeSnippet.RunWithDataFromFieldCollection(itemStub);

     Assert.AreSame(expectedText, actualText);
    }
   }
 }

and the result off course 3 green bars with 100 % test coverage.

 mocksitecorepart1a

And yes there is a lot of setup.

Now lets look at the indexing, here it becomes a little tricky since the derived BaseItem public methods isn’t overwritten on a ShimItem there for we will have to fake calls to BaseItem instead of the Item but still we need to create a stub of the item with ShimItem.

 

 [TestClass]
 public class TestIndexAccess
 {
   private CodeSnippet _codeSnippet;

   [TestInitialize]
   public void Initialize()
   {
     _codeSnippet = new CodeSnippet();
   }

   [TestCleanup]
   public void CleanUp()
   {
    _codeSnippet = null;
   }

   [TestMethod]
   public void Run_WithCheckboxFieldNotChecked_ShouldReturnEmptyString()
   {
     using (ShimsContext.Create())
     {
      ShimBaseItem.AllInstances.ItemGetID = (item, id) => "0";
      Item itemStub = new ShimItem();
      string actualText = _codeSnippet.RunWithDataFromBaseCustomItemIndex(itemStub);
      Assert.AreSame(string.Empty, actualText);
     }
   }

  [TestMethod]
  public void Run_WithCheckboxFieldCheckedButNotTextInTextField_ShouldReturnMissingText()
  {
     using (ShimsContext.Create())
     {
      ShimBaseItem.AllInstances.ItemGetID = (item, id) => id == CodeSnippet.MY_CHECKBOX_FIELD ? "1" : id == CodeSnippet.MY_TEXT_FIELD ? string.Empty : null;
      Item itemStub = new ShimItem();

      string actualText = _codeSnippet.RunWithDataFromBaseCustomItemIndex(itemStub);

      Assert.AreSame(CodeSnippet.MISSING_TEXT, actualText);
    }
  }

  [TestMethod]
  public void Run_WithCheckboxFieldCheckedButNotTextInTextField_ShouldReturnActualTextFromTextField()
  {
    using (ShimsContext.Create())
    {
       string expectedText = " Should return this string";
       ShimBaseItem.AllInstances.ItemGetID =
        (item, id) => id == CodeSnippet.MY_CHECKBOX_FIELD ? "1" : id == CodeSnippet.MY_TEXT_FIELD ? expectedText : null;

      Item itemStub = new ShimItem();

      string actualText = _codeSnippet.RunWithDataFromBaseCustomItemIndex(itemStub);

      Assert.AreSame(expectedText, actualText);
   }
 }

}
<pre>

 

And once again the result off course 3 green bars with 100 % test coverage.

mocksitecorepart1b

It might no be as smooth as Typemock mocking framework, and yes demands a bit more setup, at least at to begin with.

Sitecore MVC new Ninject Controller Factory – clean version

23/10/2012 2 comments

In this post we will have  revisit my last blog post, using Ninject with Sitecore MVC. In this new approach we will simplify the code to do the exactly same thing as in the last post LINK.
So what we want is to be able to inject Concrete implementation in the our Sitecore Controller.
We will do this by creating a ninjectc controller factory and forwarding  to the default Sitecore controller factory, so our implementation is used when Sitecore creates it’s controller. By doing it this way all standard Sitecore MVC functionality will still work, but we now have the possibility to inject our concrete implementation on creation time of the controllers.

First we need a Factory for creating the Ninject kernel


 public class NinjectKernelFactory
 {
   public IKernel Create()
   {
    return LoadAssembliesIntoKernel(new StandardKernel());
   }

   private IKernel LoadAssembliesIntoKernel(IKernel kernel)
   {
     foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
     {
      try
      {
        kernel.Load(assembly);
      }
      catch (Exception)
      {
         //Empty Catch used because ninject have problem
         //with loading some of the Sitecore MVC assemblies.
        // Method .ToString()
      }
    }
     return kernel;
   }
 }

With that in place we can create the the NinjectControllerFactory


 public class NinjectControllerFactory : DefaultControllerFactory
 {

  private IKernel _kernel;
  public NinjectControllerFactory(IKernel kernel)
  {
    _kernel = kernel;
  }

  public override void ReleaseController(IController controller)
  {
    _kernel.Release(controller);
  }

  protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
  {
    return (IController)_kernel.Get(controllerType);
  }
 }

]

All that is left is now for binding it all together in a new InitilizeContollerFactory


 public class InitializeNinjectControllerFactory
 {
   public virtual void Process(PipelineArgs args)
   {
    SetControllerFactory(args);
   }

  protected virtual void SetControllerFactory(PipelineArgs args)
  {
    NinjectKernelFactory kernelFactory = new NinjectKernelFactory();
    NinjectControllerFactory ninjectControllerFactory = new NinjectControllerFactory(kernelFactory.Create());
    SitecoreControllerFactory sitecoreControllerFactory = new SitecoreControllerFactory(ninjectControllerFactory);
    ControllerBuilder.Current.SetControllerFactory(sitecoreControllerFactory);
  }
 }

And off course we need to swap the originale InitlizeControllerFactory with our new one.

Sitecore default :

</pre>
<processor type="Sitecore.Mvc.Pipelines.Loader.InitializeControllerFactory, Sitecore.Mvc"/>

Replaced with this:


<processor type="SitecoreNinjectModule.InitializeNinjectControllerFactory, SitecoreNinjectModule"/>

Now Lets try it our I have created a really simple example first an Item with a controller rendering on.

And the sourcode for the controller


public class StoryController : SitecoreController

{
 private ITestInterface _testInterface;
 public StoryController(ITestInterface testInterface)
 {
 _testInterface = testInterface;
 }

public ActionResult From()
 {

ViewBag.Froms = _testInterface.Get();
 return View();
 }
 }

And now to the View Code

And our RazerView


@model dynamic
 <h2>From vIew</h2>

@ViewBag.Froms

And a simple TestInterface and TestClass


public interface ITestInterface
 {
 string Get();
 }


public class TestClass : ITestInterface
 {
 public string Get()
 {
 return "Hallo From Test";
 }
 }

And the output of it all

There we are a much nicer and cleaner solution presented then I came up with in my last blog post and without breaking any Sitecore functionalit, and off course you can still unit test the controller.

Sitecore MVC Ninject controller

17/09/2012 7 comments

This is last post in the series of three. As promised in my last post we will inject a repository through the construct in the controller. To do this we will use the Ninject as our IOC container, This will be a very quick walkthrough.

Also we to make it a bit easier to find controller that needs to have class’ injected we will create a derived class from the controller class’,

    public class NinjectController : Controller
    {}

Some of the assmeblies in sitecore mvc solution gives and error when trying to reflect upon them so there are a couple of catch’s in the code to handle some minor bugs.

Next we will create our controller factory  wrapping the Sitecores standard factory. This new Ninject controller factory will for the controller that should be loaded is of type nijectcontroller instantiate the corresponding concrete type of the constructers parameters.. Also this class loads all the ninject binding. Maybe it’s not so nice that it has multiple responsibility but it is left out for an exercise to refactor the code so it conforms to SRP 🙂 .

public class NinjectInitializeControllerFacotry
{
  public virtual void Process(PipelineArgs args)
  {
    this.SetControllerFactory(args);
  }

  protected virtual void SetControllerFactory(PipelineArgs args)
  {
    NinjectControllerFactory controllerFactory = new     NinjectControllerFactory(ControllerBuilder.Current.GetControllerFactory());
    ControllerBuilder.Current.SetControllerFactory(controllerFactory);
  }
}

and the controller factory it self

  public class NinjectControllerFactory : SitecoreControllerFactory
  {
    public NinjectControllerFactory(IControllerFactory innerFactory) : base(innerFactory)
    {
    }

    public override IController CreateController(RequestContext requestContext, string controllerName)
    {
      Assert.ArgumentNotNull(requestContext, "requestContext");
      Assert.ArgumentNotNull(controllerName, "controllerName");
      try
      {
         IController controller = ICreateController(requestContext, controllerName);
         return controller;
      }
      catch (Exception exception)
      {
        if (!MvcSettings.DetailedErrorOnMissingController)
        {
          throw;
        }
        return new ErrorHandlingController(controllerName, exception);
     }
   }

   public override void ReleaseController(IController controller)
   {
    var disposable = controller as IDisposable;

    if (disposable != null)
    {
      disposable.Dispose();
    }
  }

  private IController ICreateController(RequestContext requestContext, string controllerName)
  {
    string fullControllerName = string.Format("{0}Controller", controllerName);
    Type ninjectController = FindSpecificNinjectController(fullControllerName);
    if (ninjectController != null)
    {
      return (IController)Kernel.Get(ninjectController);
    }
    return base.CreateController(requestContext, controllerName);
  }

  private Type FindSpecificNinjectController(string controllerName)
  {
    IEnumerable<Type> ninjectControllers = GetNinjectControllers();
    if(ninjectControllers.Any())
    {
     Type selectedNincjectController = ninjectControllers.FirstOrDefault(controller => controller.Name == controllerName);
     if (selectedNincjectController != null)
     return selectedNincjectController;
   }
   return null;
  }

 private IEnumerable<Type> GetNinjectControllers()
 {
    List<Type> types = new List<Type>();
    foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
    types.AddRange(FindDerivedTypes(assembly, typeof(NinjectController)));
    return types;
 }
 private IEnumerable<Type> FindDerivedTypes(Assembly assembly, Type baseType)
 {
   try
   {
    return assembly.GetTypes().Where(t => baseType.IsAssignableFrom(t));
   }
   catch (Exception)
   {
    return new List<Type>();
 }
 }

  private static IKernel _kernel;
  private IKernel Kernel
  {
   get
   {
    if (_kernel == null)
      CreateKernel();
     return _kernel;
    }
 }

protected void CreateKernel()
 {
   _kernel = new StandardKernel();
    foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
   {
    if (HasNinjectModules(assembly))
    _kernel.Load(assembly);
  }
 }

public static bool HasNinjectModules(Assembly assembly)
 {
   Type baseType = typeof (NinjectModule);
   try
   {
    return assembly.GetTypes().Any(t => baseType.IsAssignableFrom(t));
   }
  catch (Exception)
  {
    return false;
  }
  }
}

So all that is left is to overwrite the standard controller factory.


<initialize>
 <processor type="SitecorePresentation.SitecoreMVCRoutes,SitecorePresentation">
 <mvcIgnoreHomePage>false</mvcIgnoreHomePage>
 </processor>
 <processor type="Sitecore.Mvc.Pipelines.Loader.InitializeGlobalFilters, Sitecore.Mvc"/>
 <processor type="SitecoreMVCNinjectExtension.NinjectInitializeControllerFacotry, SitecoreMVCNinjectExtension"/>
 <!--<processor type="Sitecore.Mvc.Pipelines.Loader.InitializeControllerFactory, Sitecore.Mvc"/>-->
 <processor type="Sitecore.Mvc.Pipelines.Loader.InitializeRoutes, Sitecore.Mvc"/>
 </initialize>

Next we can rewrite the controller from the last episode to conform to the new ninjectcontroller


public class NinjectItemController : NinjectController
 {
 private readonly IChildItemRepository _childItemRepository;
 public NinjectItemController(IChildItemRepository childItemRepository)
 {
 _childItemRepository = childItemRepository;
 }

public JsonResult Index(string id)
 {
 return Json(CreateObject(_childItemRepository.Get(id)), JsonRequestBehavior.AllowGet);
 }

&nbsp;

private IEnumerable<object> CreateObject(IEnumerable<Item> items)
 {
 List<object> objectList = new List<object>();
 foreach (Item item in items)
 objectList.Add(new { item.Name });
 return objectList;
 }

}

The repositories from the last post looks the samen but are listed below.

</pre>
public interface IChildItemRepository
{
IEnumerable<Item> Get(string parentItemId);
}
<pre>
</pre>
public class ChildItemRepository : IChildItemRepository
{
public virtual IEnumerable<Item> Get(string parentItemId)
{
ID parentId;
if(ID.TryParse(parentItemId,out parentId))
return GetChildNodes(parentId);
return new List<Item>();
}

private IEnumerable<Item> GetChildNodes(ID parentId)
{
Item parentItem = Sitecore.Context.Database.GetItem(parentId);
return parentItem.GetChildren();
}
}

Now to ninject magic the ninject module that factory are loading bindings from.


public class ChildItemRepositoryNinjectModule : NinjectModule
{
public override void Load()
{
Bind<IChildItemRepository>().To<ChildItemRepository>();

}
}

And of course now we can rewrite out unittest to test the new controller.


public class ItemControllerTest
 {
 [Test]
 public void ItemControllWithNoIdShouldReturnEmptyList()
 {
 IChildItemRepository childItemRepositoryStub = Substitute.For<IChildItemRepository>();
 childItemRepositoryStub.Get(Arg.Any<string>()).Returns(new List<Item>());
 NinjectItemController controller = new NinjectItemController(childItemRepositoryStub);

 JsonResult result = controller.Index(string.Empty);
 Assert.That(result.Data,Is.Empty);
 }

[Test]
 public void ItemControllWithInvalideIDShouldReturnEmptyList()
 {

IChildItemRepository childItemRepositoryStub = Substitute.For<IChildItemRepository>();
 childItemRepositoryStub.Get(Arg.Any<string>()).Returns(new List<Item>());
 NinjectItemController controller = new NinjectItemController(childItemRepositoryStub);
 JsonResult result = controller.Index("invalidID");
 Assert.That(result.Data, Is.Empty);
 }

[Test]
 public void ItemControllWithValidIdShouldReturnJsonListWithItemNames()
 {
 IChildItemRepository childItemRepositoryStub = Substitute.For<IChildItemRepository>();
 List<Item> childList = new List<Item>();

 childList.Add(new ItemStub("stub-a"));
 childList.Add(new ItemStub("stub-b"));
 childList.Add(new ItemStub("stub-c"));
 childList.Add(new ItemStub("stub-d"));

Guid itemGuid = Guid.NewGuid();
 childItemRepositoryStub.Get(itemGuid.ToString()).Returns(childList);
 NinjectItemController controller = new NinjectItemController(childItemRepositoryStub);
 JsonResult result = controller.Index(itemGuid.ToString());

List<object>resultData = (List<object>) result.Data; ;
 Assert.AreEqual(4,resultData.Count());
 Assert.AreEqual(resultData[0].ToString(),"{ Name = stub-a }");
 Assert.AreEqual(resultData[1].ToString(), "{ Name = stub-b }");
 Assert.AreEqual(resultData[2].ToString(), "{ Name = stub-c }");
 Assert.AreEqual(resultData[3].ToString(), "{ Name = stub-d }");
 }
 }

The import thing about the rewrite of the test are the ugly SET on the itemctroller is removed as the repository is passed in as contructor argument.The result from the test

As a last service the image below shows the file structure in visual studio .

Thats all, now we can create easy to test controllers using a repository pattern.

Unit testing our MVC Controller for Sitecore

10/07/2012 Leave a comment

Is this post and as promised, we will unit test the controller we created in the last post.
So we will rewrite the controller a tiny little bit, so we can inject a child item repository, ie. creating a stub for the repository. Since Sitecore as default doesn’t ship with ControllerFactory where it is possible use dependency inject we will rewrite the controller instead, so it has a default repository it uses when Sitecore is instantiating the controller, and one it uses when testing, or more precisely you can pass one in to Repository property. The updated controller code is listed below. In my next post we will extend Sitecore so we can inject class through the contructor with dependency Inject using Ninject.

public class ItemController : Controller
{
private IChildItemRepository _childItemRepository;

public JsonResult Index(string id)
{
return Json(CreateObject(ChildItemRepository.Get(id)), JsonRequestBehavior.AllowGet);
}
public IChildItemRepository ChildItemRepository
{
get { return _childItemRepository ?? (_childItemRepository = new ChildItemRepository()); }
set { _childItemRepository = value; }
}

private IEnumerable<object> CreateObject(IEnumerable<Item> items)
{
List<object> objectList = new List<object>();
foreach (Item item in items)
objectList.Add(new { item.Name });
return objectList;
}

}

Now the three test cases
1. No id supplied the controller should return an empty result.
2. Supplied  with an invalide Guid the controller should return an empty result.
3. Supplied with a valid guid, the controller should return a JSon result with  the item names for all child items placed under the node with specified Guid,

Now for the Unit test class, as a mocking framework I’ve used NSubstitute. I’ve used the ItemStub I did in the this post Unit testing with Sitecore Item.  The code for this test Item is also as a service listet below.

public class ItemStub : Item
{
public ItemStub(string itemName)
: base(ID.NewID, new ItemData(new ItemDefinition(ID.NewID, itemName, ID.NewID, ID.NewID),Sitecore.Globalization.Language.Invariant, new Sitecore.Data.Version(1), new FieldList()), new Database("dummy"))
{
}

}

[TestFixture]
 public class ItemControllerTest
 {
 [Test]
 public void ItemControllWithNoIdShouldReturnEmptyList()
 {
 IChildItemRepository childItemRepositoryStub = Substitute.For<IChildItemRepository>();
 childItemRepositoryStub.Get(Arg.Any<string>()).Returns(new List<Item>());
 ItemController controller = new ItemController();
 controller.ChildItemRepository = childItemRepositoryStub;
 JsonResult result = controller.Index(string.Empty);
 Assert.That(result.Data,Is.Empty);
 }

[Test]
 public void ItemControllWithInvalideIDShouldReturnEmptyList()
 {

IChildItemRepository childItemRepositoryStub = Substitute.For<IChildItemRepository>();
 childItemRepositoryStub.Get(Arg.Any<string>()).Returns(new List<Item>());
 ItemController controller = new ItemController();
 controller.ChildItemRepository = childItemRepositoryStub;
 JsonResult result = controller.Index("invalidID");
 Assert.That(result.Data, Is.Empty);
 }

[Test]
 public void ItemControllWithValidIdShouldReturnJsonListWithItemNames()
 {
 IChildItemRepository childItemRepositoryStub = Substitute.For<IChildItemRepository>();
 List<Item> childList = new List<Item>();

childList.Add(new ItemStub("stub-a"));
 childList.Add(new ItemStub("stub-b"));
 childList.Add(new ItemStub("stub-c"));
 childList.Add(new ItemStub("stub-d"));

Guid itemGuid = Guid.NewGuid();
 childItemRepositoryStub.Get(itemGuid.ToString()).Returns(childList);
 ItemController controller = new ItemController();
 controller.ChildItemRepository = childItemRepositoryStub;
 JsonResult result = controller.Index(itemGuid.ToString());

List<object>resultData = (List<object>) result.Data; ;
 Assert.AreEqual(4,resultData.Count());
 Assert.AreEqual(resultData[0].ToString(),"{ Name = stub-a }");
 Assert.AreEqual(resultData[1].ToString(), "{ Name = stub-b }");
 Assert.AreEqual(resultData[2].ToString(), "{ Name = stub-c }");
 Assert.AreEqual(resultData[3].ToString(), "{ Name = stub-d }");
 }

And a screenshot of the test status.

I know that there probably exists better ways to test json results, but it is out of scope for this post, and yes if it should be “clean tests” each test should only contain one assert, but is left for as an exercise for you :).

In the next post we will extend Sitecore so that we can create Controllers through dependency injection, with Ninject as an IoC container. With this solution we don’t need the ugly Set in the Repository Property.

Unit testing Sitecore with Typemock Isolater.

27/04/2012 5 comments

In my last post I gave a stub example for a Sitecore Item. With the stub item you could test functionality for retrieving field data, which greatly limits the functionality you can test. So in this post I will have a look at the more advanced mocking framework Isolator from Typemock.  With the Isolator framework it is possible to intercept calls for methods that normally wouldn’t be possible, for example static methods. How may this help us? Since Sitecore hasn’t made it any easier to do unit testing with a great deal of static classes and methods alike, you will be able to mock or stub them out with the Isolator framework. The following is a simple example for testing functionality for Item.Children, ie. Sitecores Childlist.

Here we have a simple piece of code that, given a specific Template ID, adds an item to a list and returns the list.

public class SectionFactory
{
   public static IEnumerable<Section> CreateCollection(Item columnItem)
   {
      ID sectionTemplateId = new ID(Constants.Templates.Section);
      ChildList children = columnItem.Children;
      List<Item> sections = new List<Section>();
      foreach (Item child in children)
      {
         if (child.TemplateID == sectionTemplateId)
            sections.Add(new Section(child))

      }

     return sections;
 }
}

Since getting the children for a Item invokes more than a few static methods and classes it is impossible to stub the functionality using most mocking frameworks. But with the Isolator Framework it is possible.

[TestFixture]
 public class SectionFactoryTest
 {
 [Test]
 public void SectionFactoryNoChildrenReturnEmpyList()
 {
 Item stub = Isolate.Fake.Instance<Item>();
 ChildList childlist = Isolate.Fake.Instance<ChildList>();
 Isolate.WhenCalled(() => stub.Children).WillReturn(childlist);
 IEnumerable<Section> sectionList = SectionFactory.CreateCollection(stub);
 Assert.AreEqual(new List<Section>(), sectionList);
 }

[Test]
 public void SectionFactoryOneChildReturnEmpyList()
 {
 Item stub = Isolate.Fake.Instance<Item>();
 Item child = Isolate.Fake.Instance<Item>();
 ChildList childlist = Isolate.Fake.Instance<ChildList>();

ID sectionTemplate = new ID(Constants.Templates.Section);
 Isolate.WhenCalled(() => child.TemplateID).WillReturn(sectionTemplate);
 Isolate.WhenCalled(() => childlist).WillReturnCollectionValuesOf(new List<Item>(){child});
 Isolate.WhenCalled(() => stub.Children).WillReturn(childlist);

ID link = new ID(Constants.Fields.Section.Links);
 Isolate.WhenCalled(() => LinkRepository.GetCollection(child, link)).WillReturn(null);

IEnumerable<Section> sectionList = SectionFactory.CreateCollection(stub);
 Section section = sectionList.FirstOrDefault();
 Assert.That(section, Is.Not.Null);

 }

[Test]
 public void SectionFactoryOneValidSectionChildChildReturnEmpyList()
 {
 Item stub = Isolate.Fake.Instance<Item>();
 Item sectionChild = Isolate.Fake.Instance<Item>();
 Item child = Isolate.Fake.Instance<Item>();
 ChildList childlist = Isolate.Fake.Instance<ChildList>();

ID sectionTemplate = new ID(Constants.Templates.Section);
 Isolate.WhenCalled(() => sectionChild.TemplateID).WillReturn(sectionTemplate);
 Isolate.WhenCalled(() => child.TemplateID).WillReturn(null);
 Isolate.WhenCalled(() => childlist).WillReturnCollectionValuesOf(new List<Item>() { child, sectionChild });
 Isolate.WhenCalled(() => stub.Children).WillReturn(childlist);

ID link = new ID(Constants.Fields.Section.Links);
 Isolate.WhenCalled(() => LinkRepository.GetCollection(child, link)).WillReturn(null);

IEnumerable<Section> sectionList = SectionFactory.CreateCollection(stub);

 Assert.AreEqual(1,sectionList.Count());

}
 }

So with the above test we managed to get a 100% test coverage for the code.
And with the Isolator Framework we could even mock out the Sitecore.Context. The Isolater framework is must a have if you want to do unit testing with Sitecore.

Unit testing with Sitecore Item

07/02/2012 7 comments
This post is about how to do unit testing  with Sitecore. Off course this is not easily done, because Sitecore requires a “context” to work.  There are a couple of blogs out there , that explains how to setup either a custom test runner, where you can xecute tests through a webpage. or alternative setup an app_config file so you can work with Sitecore without a httpcontext. Links to both examples are given in bottom of this posts.
Both are really good, but I would categorize testing this way more as Integrations tests.  Since they both depend on external resources  such as  Sitecore Database or httpcontext, it would be more fair to  call them Integration tests. Not that you shouldn’t do integration test you SHOULD, but theese are more “heavy to run”. A unit is the smallest testable part of an application, and a unit test should not depend on the external things such as a database, file system or a like, and more they should run fast, and by a click of a button. I’ve recently read the book  Working Effectively with Legacy Code by Michael Feathers, and it got me thinking there got a be an alternative way to do unit testing with Sitecore.
Finally I’ve recently had a discussion with one of collegeues, the discussion was about how you could do unit test with Sitecore and what you would win by doing so. He claimed that test would be more complex then the code it test, and you wouldn’t gain anything from such tests. This inspired me to do some extensive testing. To prove him wrong I found some code he wrote for a Sitecore solution see below, the code is taken from a navigation component and finds the navigation title fom a item,  navigation title is only shown if the item if   “show in menu”  checkboxfield is checked. Keep in mind the that I picked this example because it is simple.
public class NavigationTitleFactory
 {
 public static string Create(Item item)
 {
 bool showInNavigation = item.GetCheckBoxField(new ID(Constants.Fields.Navigation.Show));

if (!showInNavigation)
 {
 return string.Empty;
 }

string navigationTitle = item.GetStringField(new ID(Constants.Fields.Navigation.Title));

 if (string.IsNullOrEmpty(navigationTitle))
 navigationTitle = item.Name;

 return navigationTitle;
 }
 }

So the first problem that you meet is that a Sitecore Item is difficult  to mock or stub out for test, it would have been really nice if it had  inherit from a interface or had some virtual methods you could override in  a test implementation of with a mocking framwork.
But it turns out you can actually instantiate a Sitecore Item all  you have to do is passing in a lot of nulls “W.E.W.L.C by  M.Feather page 121” see the result below.
public class TestItem : Item
 {
 public TestItem(FieldList fieldList,string itemName="dummy")
 : base(new ID(new Guid()), new ItemData(new ItemDefinition(new ID(new Guid()), itemName, new ID(new Guid()), new ID(new Guid())), Language.Invariant, new Sitecore.Data.Version(1), fieldList), new Database("web"))
 {

}
 }
 With this test item, writing test should now become a lot easier. The itemName is optional because offen you dont care about the name of your item, but for this show case we do.
If you like ,you could pass in addiational arguments to the test item like database name, language, or version. and would still work. The fieldlist arguments should contain the list of field values you gonna use in your test, the item fields can only be referenced with Sitecore id’s as you will see in the example below. Now back to code challenge from my colleague . I want to test the logic for the  navigation title factory liseted above. Here are the test cases.

  1. An Item with show in navigation not checked – it should return an empty string.
  2. An item with show in navigation checked but no navigation titel should return the Name of the Item.
  3. An item with show in navigation checked and with a navigation title, it should return the value of the navigation title.

The test code i listed below should give 100% test coverage of the code.

[TestFixture]
 public class NavigationTitleFactoryTest
 {
 [Test]
 public void CreateItemWithShowInMenuFalseShouldReturnEmptyString()
 {
 FieldList stubFieldList = new FieldList();
 stubFieldList.Add(new ID(Constants.Fields.Navigation.Show),"0");
 stubFieldList.Add(new ID(Constants.Fields.Navigation.Title),"NavigationTitle");
 Item stub = new TestItem(stubFieldList);

 string navigationTitle = NavigationTitleFactory.Create(stub);

 Assert.IsNullOrEmpty(navigationTitle);
 }

[Test]
 public void CreateItemWithShowInMenuTrueNoNavigationTitleShouldReturnItemName()
 {
 FieldList stubFieldList = new FieldList();
 stubFieldList.Add(new ID(Constants.Fields.Navigation.Show), "1");
 stubFieldList.Add(new ID(Constants.Fields.Navigation.Title), "");
 Item stub = new TestItem(stubFieldList,"myItemName");
 string navigationTitle = NavigationTitleFactory.Create(stub);

Assert.AreEqual("myItemName", navigationTitle);
 }

[Test]
 public void CreateItemWithShowInMenuTrueShouldReturnItemNavigationTitle()
 {
 FieldList stubFieldList = new FieldList();
 stubFieldList.Add(new ID(Constants.Fields.Navigation.Show), "1");
 stubFieldList.Add(new ID(Constants.Fields.Navigation.Title), "NavigationTitle");
 Item stub = new TestItem(stubFieldList);
 string navigationTitle = NavigationTitleFactory.Create(stub);

Assert.AreEqual("NavigationTitle",navigationTitle);
 }
 }
This is  a simple example of how to do some unit testing with sitecore. Off course there are some problems with this approach you can’t access more complex attributes and functions of the Sitecore item, for example Children, path, and  functions in general that needs to communicate with Sitecore. But you can test more complex logic that are based in field values alone.
But what did we win with these tests, lets look at it this way. First of i saved time going in to Sitecore creating items setting field values and publishing, agreed it doesn’t take that long but with test like this i can repeat verification of my code by a click of a button. Also Should the Navigation Title Factory really care about which items it get from sitecore ie  the database  pr which context it runs in ? And it would even be pretty simple to add fallback from navigation title to another field value instead of item name and test this new functionality and ensure that the old functionality still works as excepted. And this is precisely what you want from a unit tests.With a unit test you it should be easy to change/modify ,refactor or add functionality to existing code and easily verify that you didn’t brake anything.
I wouldn’t test pure datacontainers, Items that only holds data to be shown. I would prefer to test these with integrationtest.

Allstair Deneys blog on unit testing with
Sitecore using a custom test runnner can be found here.How to change config files to work with Sitecore without a “context” here. By Mike Edwards