Looking at what areas I see as being a focus in the SharePoint development space,  how I will continue to push TDD but will also, now that people are starting to talk about good SharePoint development practices, start to look at the wide picture – looking at how we complement the Unit Tests with integration tests,  looking at ways to automate use acceptance tests and generally looking at ways to make the code better so that testers can focus on the scenarios and complex tests rather than dealing with the ‘stupid bugs’.

Original post on Typemock Blog

Unit Testing Workflows

In my response to a question from Aaron Weiker I said that I would like to see much more guidance and investigation into the way we approach Unit Testing workflows in SharePoint,  so it was great to find Richard Fennell is doing a lot of work in this area.  I have been working with Typemock Isolator, CThru and SilverUnit testing recently (post coming) and was very interested to see that Richard had picked up this whilst looking for a possible solution to the challenges of Unit Testing SharePoint workflows; something I have to confess I had not even considered.

I’m looking forward to seeing where Richard gets with this and also the use of Fit/Fitness, although I’m personally not a big fan of the way tables are used to define the tests.

Integration Testing SharePoint from MSTest

Having been a bit behind with my reviews of the latest Codeplex P&P project I missed the discussion with Francis on how they found a use for Typemock Isolator to do Integration tests.

The code is really very very simple,  many will be glad to hear, and deals with the places where your code makes a call to SPContext.Current or SPFarm.Local.

The simple ideas really are the best ones.

As you can see,  a few small steps for testing but big steps for SharePoint testing and a demonstration that in general the SharePoint community is committed to improving the way solutions are developed.

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.
Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle – and for the launch will be giving out FREE licenses to bloggers and their readers.
The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.
Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.
The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you’ll get a license automatically (even if more than 60 submit) during the first week of this announcement.
Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.
Go ahead, click the following link for more information on how to get your free license.

I’ve not had the chance to try out the Ivonna or SilverUnit add-ons to the framework yet, but will be looking at these in the near future and they can help you test more of your SharePoint solutions.

Richard Fennell – Testing SharePoint Workflows using TypeMock Isolator (part 1, part 2 and part 3) – Richard is also going to be talking at a few NextGen meetings on the subject.

SharePoint Dev Wiki is really starting to get some good content not just on unit testing but on the whole development field.

Jeremy Thake (creator of SharePoint Dev Wiki) did a great usergroup meeting web cast on SharePoint Development with Unit Testing

I’ve previously mentioned the Patterns and Practices work and they have started to do some great Channel 9 videos which really do make this so much more accessible.  Brilliant Job!

If you have any links or posts on the subject please share by adding a link in the comments, and if you’ve done something new and exciting help the SharePoint Dev Wiki by posting details.

Looks like my predictions are starting to come true,  people really are doing SharePoint development better

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

I did have some slides to set the scene (see below), to give some background to TDD and raise the issues around the use of the word TEST.  We also looked at 10 reasons TDD sucks, with a slight SharePoint slant,  and quickly got into Visual Studio where the real learning was to happen.

The user story was to develop a Magic 8 Ball web part that could have custom answers defined in a SharePoint list.  The finished code is available on CodePlex and it is planned to extend this solution over time to expand on the ideas.  My main issue with just getting the finished code is the learning is in the process and it can be hard to see how the design was driven by the code.   I am planning to do a web cast on this to show this process.

CodePlex project now available  http://www.codeplex.com/sp8ball

Winners

The guys at Typemock we very generous in donating 3 copies of Isolator for SharePoint which is an essential component for anyone doing unit testing in a SharePoint environment.  The lucky winners were

Mark Freeman
Shahar Tamari
Kennedy Duncan

Each of you will receive a free license for Isolator for SharePoint,  for those that did not win Typemock are running a special discount.

This post is part of a series on Test Driven Development – Using Dependency Injection

We introduced some terms previously to help describe some of the things we need to do in order to make our code more testable.  In this step we are going to start the refactor to  support Dependency Injection in the RandomMessage class.

The code that is causing us a problem when using Isolator for SharePoint is in the GetRandomMessage method.

        public string GetRandomMessage(string WebUrl)

        {

            string message = "";

            try

            {

                using (SPSite site = new SPSite(WebUrl))

                {

                    using (SPWeb web = site.OpenWeb())

                    {

                        SPList messages = web.Lists["Messages"];

                        int rndMessage = GetRandomNumber(messages.ItemCount);

                        message = messages.Items[rndMessage].Title;

                    }

                }

            }

//*... snipped for brevity ...*//

        }

    }

What we need to do is use Dependency Inversion, that is we want to allow our calling code to decide what is used to get the random number.  To achieve this we need to create an interface for a class that we will allow us set define the way get our random number.

Visual Studio was really designed with agile developers in mind.   In order to achieve our refactoring we can do the following.

Highlight the method GetRandomNumber, right click on the code and choose Refactor.  Should see something similar to the image below

Choose the Extract Interface option which will provide you with a dialog to define the new interface name (IRandomNumber), the .cs file and also the methods that will be extracted.

Click OK and Visual Studio will do some of the work for us.  It does not however do everything so we will continue to fix up the code.

1. In the newly created IRandomNumber.cs files make the interface Public

As we are doing TDD we need to review our tests as the ones for the GetRandonNumber method will now be against a new object.  You may want to split out the tests into another class or .cs file but for now we will just refactor the tests that will change.

The tests should look something like below,  the code won’t at this point compile as we don’t yet have this class.

        [Test]

        public void GetRandomNumber_PostiveRange_ReturnValueInRange()

        {

            ObjectModel.RandomNumber randomNumber = new ObjectModel.RandomNumber();

            int messageId = randomNumber.GetRandomNumber(1);

            Assert.AreEqual(0,messageId);

        }

        [Test, ExpectedException(typeof(ArgumentOutOfRangeException))]

        public void GetRandomNumber_Zero_ThrowException()

        {

            ObjectModel.RandomNumber randomNumber = new ObjectModel.RandomNumber();

            int messageId = randomNumber.GetRandomNumber(0);

        }

        [Test, ExpectedException(typeof(ArgumentOutOfRangeException))]

        public void GetRandomNumber_Negative_ThrowException()

        {

            ObjectModel.RandomNumber randomNumber = new ObjectModel.RandomNumber();

            int messageId = randomNumber.GetRandomNumber(-1);

        }

        [Test]

        public void GetRandomNumber_MaxValue_ReturnValueInRange()

        {

            ObjectModel.RandomNumber randomNumber = new ObjectModel.RandomNumber();

            int messageId = randomNumber.GetRandomNumber(int.MaxValue);

            Assert.GreaterOrEqual(messageId, 0);

            Assert.LessOrEqual(messageId, int.MaxValue);

        }

Add a new class to the UnitTest.ObjectModel project called RandomNumber.  Make this class public and implement the interface IRandomNumber.  Next we need to remove the code from the RandomMessage class.   This involves removing the implementation of the IRandomNumber interface that Visual Studio added and also moving the GetRandomNumber code into our new class which should look similar to the code below.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace UnitTest.ObjectModel

{

    public class RandomNumber : IRandomNumber

    {

        public int GetRandomNumber(int max)

        {

            if (max < 1)

                throw new ArgumentOutOfRangeException(

                    "max", max, "Maximum value must be greater than or equal to 1");

            Random rnd = new Random();

            return rnd.Next(max);

        }

    }

}

At the moment our code will be in a state of flux,  it still won’t compile as the GetRandomMessage method needs to be updated,  we will add a new instance of the RandomNumber class and call this method on this.  We’re not doing the dependency injection just yet.

Once this change is implemented we should be able to compile the UnitTest.ObjectModel project.   To compile the tests we need to comment out the call we make to mock out this method (this was the method that caused us issues testing with Isolator for SharePoint).

In the method GetRandomMessage_MultipleMessages_ReturnMessage comment out the line

//Isolate.WhenCalled(() => message.GetRandomNumber(1000)).WillReturn(99);

Our solution should now compile and running the tests all except the one above should pass.

A quick recap shows that we have refactored our solution, extracting the RandonNumber method into it’s own class based on an interface and run all the tests to show the code works as expected.   This is one of the big values of doing TDD,  we can make some major refactors in our code and know when we’re complete because the tests pass.

In the next next step we are going to use the IRandomNumber interface to implement Dependency Injection.

Step 2. Implementing dependency injection into GetRandomMessage

In order to keep the white paper easy to follow we used the Isolator features to fake the call to our GetRandomNumber() method as part of the test GetRandomMessage_MultipleMessages_ReturnMessage.

[Test]

public void GetRandomMessage_MultpleMessages_ReturnMessage()

{

    //Arrange

    SPSite site = Isolate.Fake.Instance<SPSite>(Members.ReturnRecursiveFakes);

    Isolate.Swap.NextInstance<SPSite>().With(site);

    Isolate.WhenCalled(() => site.OpenWeb().Lists["Messages"].ItemCount).WillReturn(1000);

    Isolate.WhenCalled(() => message.GetRandomNumber(1000)).WillReturn(99);

    Isolate.WhenCalled(() => site.OpenWeb().Lists["Messages"].Items[99].Title).WillReturn("Message One Hundred");

    //Act

    string rndMessage = message.GetRandomMessage("http://validsiteurl");

    //Assert

    Assert.AreEqual("Message One Hundred", rndMessage);

}

This makes for a simple test and helped us focus on the objective of testing the SharePoint object model, however this test does not work if we use Isolator for SharePoint which can only fake SharePoint objects. With this version you will get an error advising of the need to upgrade to the commercial version.

UnitTest.ObjectModel.Test.RandomMessage.GetRandomMessage_MultpleMessages_ReturnMessage:

TypeMock.TypeMockException :

*** Can not fake non-SharePoint type UnitTest.ObjectModel.RandomMessage with current license.

In order to fake non SharePoint types please upgrade to Typemock Isolator Commercial license

See more information at http://www.typemock.com/sharepointpage.php.

There are a few solutions to the problem

1. Upgrade to the Full version of Typemock Isolator
2. Introduce another mocking framework like NMock to mock this method
3. Redesign you application to be more testable and make this test possible without using Typemock Isolator

NMock is an open source mocking framework that provides similar functionality to Typemock however NMock (or any other mocking framework) is unable to fake SharePoint objects as they make use of sealed classes.  We would recommend that you don’t attempt to work with two different mocking frameworks at the same time as this will make you testing much more difficult to follow and maintain.

There has been a lot of debate around Typemock being too powerful and if the value of designing testable code is as important now that Typemock can solve these issues.

We’re not going to argue the case for or against here; We’ll work on the assumption that you have Isolator for SharePoint and will redesign for testability.

Our refactoring of the project has been broken down into 3 steps proceeded by an introduction to some common vocabulary will be published over the next few days.

• Introduction to common TDD vocabulary
• Step 1. Refactoring
• Step 2. Implementing dependency injection into GetRandomMessage
• Step 3. Review and whats next

[Test]
public void GetRandomMessage_SiteNotFound_ReturnErrorMessage()
{
    //Arrange
    using (RecordExpectations expections = RecorderManager.StartRecording())
    {
        expections.ExpectAndThrow(new SPSite("http://invalid_url"),  new FileNotFoundException());
    }

    //Act
    string rndMessage = message.GetRandomMessage("http://invalid_url");

    //Assert
    Assert.That(rndMessage.StartsWith("Error"));
    Assert.That(rndMessage.Contains("Site could not be found"));
}

With the release of V5.1.2 of Isolator for SharePoint a new API has been added to the AAA syntax to support just this scenario.

Isolate.Swap.NextInstance<T>().ConstructorWillThrow();

Our tests will now look like this:

[Test]
public void GetRandomMessage_SiteNotFound_ReturnErrorMessage()
{
    //Arrange
    Isolate.Swap.NextInstance<SPSite>().ConstructorWillThrow(new FileNotFoundException());

    //Act
    string rndMessage = message.GetRandomMessage("http://invalid_url");

    //Assert
    Assert.That(rndMessage.StartsWith("Error"));
    Assert.That(rndMessage.Contains("Site could not be found"));
}

You will agree this is a much easier API and helps to lower the barrier to Test Driven SharePoint development a little bit more.   We will be updating our white paper to reflect this change and updating out code over the next few days.

Update 25 Nov 08:

You will also need to add the [ClearMocks] directive to the start of you Test Fixture to ensure Isolator clears up after each test.

[TestFixture]
[ClearMocks]
public class RandomMessage

Also one of the tests will now fail if you are using the new Isolator for SharePoint with the following error:

TypeMock.TypeMockException:

*** Can not fake non-SharePoint type UnitTest.ObjectModel.RandomMessage with current license. In order to fake non SharePoint types please upgrade to Typemock Isolator Commercial license

See more information at http://www.typemock.com/sharepointpage.php.

I will be following up with the Guys at Typemock to see how much room there will be to support non SharePoint objects in the SharePoint Edition for just these scenarios.

Take a look at our white paper showing Isolator in action and how this really does make Unit Testing your SharePoint solutions that much easier.

Unit Testing SharePoint Solutions – Getting into the Object Model

Quote from Typemock Blog:

Typemock are offering their new product for unit testing SharePoint called Isolator For SharePoint, for a special introduction price. it is the only tool that allows you to unit test SharePoint without a SharePoint server. To learn more click here. The first 50 bloggers who blog this text in their blog and tell us about it, will get a Full Isolator license, Free. for rules and info click here.

The white paper and associated code can be found here Unit Testing SharePoint Solutions – Getting into the Object Model

The first document in the Beginners Guide to Test Driven Web Part Development Series provided an introduction to unit testing, a look at how TDD influences your design and makes your code testable. That document deliberately avoided testing the SharePoint Object Model as in order to do this we need to introduce the concept of mocking.

This second document in the series will cover the concept of mocking, specifically looking at the new Typemock Isolator (V5.1.1 or later) AAA API to demonstrate testing against SPSite, SPWeb, SPList and SPListItem objects.

Some of the key things you should get from this white paper are

• How to unit test the object model
• These unit tests are much less brittle using the new Isolator AAA API
• You do not need a specific SharePoint configuration on your development machine, we are not Integration testing
• Reinforce TDD approach to SharePoint development

The white paper is part of the Beginners Series but introduces some fairly advanced concepts, as with SharePoint the learning curve can be fairly steep.  You can work through this white paper on it’s own but I recommend looking at the first part as this goes into more detail about TDD.

The white paper and associated code can be found here Unit Testing SharePoint Solutions – Getting into the Object Model

We welcome you comments and suggestion for improving the current white papers and also ideas for the future.