Agile Sharepoint development by 21apps and Andrew Woodward MVP

Slide deck from my Automated UI Testing of SharePoint 2010 with Visual Studio 2010 presented at the Best Practices Conferences in Washington DC in August 2010.

(more…)

As part of the 21SCRUM development project I implemented build verification testing using Visual Studio 2010.  21SCRUM has a great suit of unit tests for the core logic,  it has some integration tests (although I would like more) but I found a lot of the coding was very targeted at the User Interface.  So much so that no real changes to the core logic have been made since the beta release.

The team did a number of Spike tests ¹ to see if it was possible to do unit testing of the JavaScript code.  Unfortunately nothing that was looked at really provided the confidence or ease of use needed to become a part of the development process.

I have flirted with automated UI testing for a long time,  looking at WinRunner, Segue, QA Runner and various other tools along the way.  I actually remember doing UI testing against a FoxPro application that used OCR technology to verify the text on the screen.  The problem has always been that the tests are brittle, any slight changes to the UI and they break and it becomes a case of diminishing returns.  However having failed to find a good solution to unit testing the UI code I decided to give the new Visual Studio 2010 tools a look.

My first impressions were very good,  I actually changed the session I was doing at the SUGUK event in Wolverhampton due to being so impressed by the tools.  This post is going to be one of a number I do covering lessons learned as the team develop our test suite using these tools for real on 21SCRUM.  

The first lesson and one that you need to do before you start any UI testing is start from a known place.

Start from a known place

I quickly discovered that getting good, repeatable and maintainable automated UI tests to work over time you really have to make sure you always start at the same place.  This means no additional browser windows open,  no test web parts added to your pages, no left over’s from the last test or development.   

One of the reasons I love Unit Testing is the isolation for any real environment or the need to go through a lot of setup and tear down steps.

In order to do this properly and repeatedly you need to have a script that will refresh your test location.

The script used for 21SCRUM is simple and does the following:

• - Deletes the test site collection
• - Create the test site collection based on required site template
• - Uploads the 21SCRUM sandboxed solution to the Solution Gallery
• - Activate the 21SCRUM solution

These steps ensure that when the tests are run they always start from a clean site collection.   The script has been extended to provided sub sites and additional site collections but the changes are incremental and added as the tests demand.

Powershell

Like all good developers Powershell is the scripting language of choice.  Actually kicked off with a good old fashioned .bat file <<  interested to know if there are any alternatives to this?

The batch file RefreshSite.Bat  (powershell.exe is in my standard path)

powershell -File RefreshSite.ps1

The powershell script does the work

//Load the SharePoint Commandlets

Add-PSSnapin Microsoft.SharePoint.Powershell

//Delete the site collection – don’t prompt the user to confirm

Remove-SPSite -Identity “http://aberdovey.com” -Confirm:$false

//Create a new site collection based on the Team Site Template

Get-SPWebTemplate | Where{ $_.Title -eq “Team Site” } | ForEach-Object{ New-SPSite http://aberdovey.com –OwnerAlias DOMAIN\USER -Name “Aberdovey” -Template $_ }

//Add the solution to the solution Gallery – it must have the full path name and not a relative path

Add-SPUserSolution -LiteralPath C:\<full path to the location of the WSP>\21Scrum.Solution.wsp -Site http://aberdovey.com -Confirm:$false

// Activate the solution – and yes Microsoft have done it again with the naming!  Install means Activate

Install-SPUserSolution -Identity 21Scrum.Solution -Site http://aberdovey.com -Confirm:$false

This simple command allows the refreshing of the environment to be run quickly and ensures the tests always start from a known place.

¹ Spike Tests – short time-boxed pieces of work looking to prove an approach or providing additional knowledge to make estimates more accurate.

I had to post this quick article as its one of those can’t see the wood for the trees.

I had been trying to do a simple call back to the server to display some information about a list item.

   getStory: function (id) {

    var backLogList = this.lists.getByTitle('BackLog');

        this.itemToGet = backLogList.getItemById(id);

        context.executeQueryAsync(

        Function.createDelegate(this, com.apps.aberdovey.SprintPlanning.getStorySucceeed),

        Function.createDelegate(this, com.apps.aberdovey.SprintPlanning.onFail));

    },

    getStorySucceed: function (sender, args) {

    alert('got it');

    },

The problem was I never got anything to happen.  My onFail() had an alert and I also showed an alert when the call succeeded.   But nothing.

I reverted to IE Dev toolbar where I kept getting the error

‘b’ is null or not an object

after spending time validating my calling code and cursing the lack of good examples on the web for SharePoint 2010 ECMAScript I eventually found it. 

The delegate name for the getStorySucceed was spelt incorrectly!

It is amazing how much time you spend looking for stupid errors when doing JavaScript development.  This one I thought worth posting so that when other search for ‘b’ is null or not an object they will at least have a better idea what’s wrong.

One of the challenges with unit testing SharePoint projects is the need to fake the calls into SharePoint.  If you are a regular reader of my blog you will have seen examples of how I have been doing this using Typemock Isolator. 

Microsoft have their own isolation framework called moles.  A more accurate descripition would be isolation through detours and stubs.  Moles was developed to support Pex white box testing and one interesting development from within the team has been Behaviours.  Behaviours are really a way to model the thing you want to isolate for the test without needing to define every isolation point. 

Isolatation frameworks (regardless of technology) can result in brittle code, test code that is very tightly linked to the production code.   A simple change from List.GetItems() to List.Items[""] will cause the test to fail.

One of the samples provided with Pex is the modelling of SharePoint Behaviour that will make it much easier for people to be able to create robust tests with minimal or no additional isolation code needed.   Part of the work we are doing is to drive out the things that need to be modelled and reporting these to the Pex team.  It is not going to be easy to model the whole of SharePoint from day one,  however it should be possible to cover the areas most used.

This is where I would like some help.     Do you have any code that you use often,  code that you would like to unit test that takes a long time to isolate and that end up being brittle?

Please post examples here in the comments and we will try to get as much covered as possible.

Normally I refrain for doing simple reposts of other people blogs,  however having read the post SharePoint’s Sasquatch Memory Leak by Todd Carter I just had to help get the information out to as many people as possible.

We are all being good developers and running SPDisposeCheck regularly on our code to make sure we don’t leak memory,  however for some we still experience spiralling memory leaks that seem untraceable.  until Todd’s post that is.

Rather than hang around here you MUST read it now,  and if your experiencing issues and have SPDisposeCheck’d your application to within an inch of it’s life with no success on controlling memory you will want to implement the workaround as soon as possible.

Big Thanks to Todd find Big Foot

Firstly what is a SharePoint SPI?

No it’s not another new version, it’s a generic term that is used to describe a SharePoint Project Item within the context of a Visual Studio project.

Visual Studio 2010 has introduced a lot of great SharePoint specific features making it significantly easier to get started with SharePoint development. This post however is not about the tools, it is intended to point out one little bit of the hidden functionality that unfortunately didn’t get completed in time.

The Visual Studio tools hide away so of the configuration options in .spdata files. This is normally great as you can change these via the UI tools and everything works. However I discovered a small issue during a recent refactoring of a project.

When you create a new SharePoint SPI (for example a web part) that needs to add a reference to the assembly it updates the .spdata file with information (as below)

<?xml version="1.0" encoding="utf-8"?>
<ProjectItem Type="Microsoft.VisualStudio.SharePoint.WebPart"
   DefaultFile="MyWebpart.cs"
   SupportedTrustLevels="All"
   SupportedDeploymentScopes="Site"
   xmlns="http://schemas.microsoft.com/VisualStudio/2010/SharePointTools/SharePointProjectItemModel">
  <Files>
    <ProjectItemFile Source="Elements.xml" Target="MyWebpart\" Type="ElementManifest" />
    <ProjectItemFile Source="MyWebpart.webpart" Target="MyWebpart\" Type="ElementFile" />
  </Files>
  <SafeControls>
    <SafeControl Name="MyWebpart"
       Assembly="$SharePoint.Project.AssemblyFullName$"
       Namespace="_21apps.Sample.SPSolution" TypeName="*" IsSafe="true" />
  </SafeControls>
</ProjectItem>

 

In here you will see references to the ProjectItemFiles (.weppart and element manifest) and also an entry for the SafeControls.

If you look closely at the SafeControl entry you will see the Assembly is using a Token

Assembly=”$SharePoint.Project.AssemblyFullName$”

This is great as it allows the SafeControl to pickup the actual assembly name at compile time. The problem comes with the next part of the entry

Namespace=”_21apps.Sample.SPSolution”

As you can see this is not token based, which means that if you later decide to rename you namespace, and this is case sensitive, the SharePoint safe control entry will no longer be valid and you will get an error like the one below when you deploy the solution.

A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered on this site as safe.

For more info on what this actually means have a look at Maurice Prather’s post from back in 2005, the information is still applicable today.

Unfortunately this namespace is unlikely to be made into a Token any time soon. Perhaps one for the community to pickup in the meantime. For now it is case of being aware that you need to correct this manually if you do change your namespace.

At the recent SharePoint Conference in Vegas I took a few minutes out to talk to Gil Zilberfeld of Typemock about what 21apps is doing with SharePoint and what I see as the next steps in the community regarding SharePoint development.

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

Since attending Roy Osherove’s TDD Master Class I have been doing my daily TDD Kata, I will admit I have missed some days but generally I have been keeping up with it and really seeing the benefit.

Here I talked about what a Kata is and how it compares to Kumon Maths and I also took the opportunity to practice my reviewing techniques by looking at the best and reviewing Uncle Bobs prime factors TDD Kata.

I had promised to provide a web cast of the TDD SharePoint session that I did at the Best Practices conference, but I feel now that I need to really improve my keyboard mastery before taking on that one.  Instead I have taken the opportunity to record my current TDD Kata which is based on Roy Osheroves String Calculator.  I have limited the steps I have done in this recording as I think 30 minutes would get a little boring.

String Calculator

1. Create a simple String calculator with a method int Add(string numbers)
   1. The method can take 0, 1 or 2 numbers, and will return their sum (for an empty string it will return 0) for example “” or “1″ or “1,2″
   2. Start with the simplest test case of an empty string and move to 1 and two numbers
   3. Remember to solve things as simply as possible so that you force yourself to write tests you did not think about
   4. Remember to refactor after each passing test
2. Allow the Add method to handle an unknown amount of numbers
3. Allow the Add method to handle new lines between numbers (instead of commas).
   1. the following input is ok:  “1\n2,3″  (will equal 6)
   2. the following input is NOT ok:  “1,\n” 
   3. Make sure you only test for correct inputs. there is no need to test for invalid inputs for these katas
4. Allow the Add method to handle a different delimiter:
   1. to change a delimiter, the beginning of the string will contain a separate line that looks like this:   “//[delimiter]\n[numbers.]” for example “//;\n1;2″ should return three where the default delimiter is ‘;’ .
   2. the first line is optional. all existing scenarios should still be supported

The idea behind TDD is to work through one thing at a time,  so in the example we start with 0 numbers (or empty string) and progress through each requirement continuing to adopt the Red, Green, Refactor approach – hopefully this will be clear from the video.

The Kata is not about knowing how to solve this problem, it is about knowing how to do things quickly and also knowing how to approach problems using TDD. 

In this example,  as in my day job, I am using ReSharper to aid refactoring,  NUnit 2.5 for my tests as this supports TestCase and TestDriven.Net to run the tests.

I have setup some live templates for the Test method and common Assert.AreEquals statements and have added a Keyboard shortcut to Re-Run the tests in TestDriven.Net (I use Alt + R).

Hope you enjoy the video, I have left the sound off - if you perfer some nice background music I can edit and add some

Would love to hear your thoughts on this.

TDD Kata – Calculator Part 1 by AndrewWoody from Andrew Woodward on Vimeo.

You can download the WMV video to watch locally from the Vimeo site.

The numbers are in and I think this small sample really gives a good view as to the way people are approaching their SharePoint development projects.

Numbers taken from a one week poll asking people which build servers they used on their SharePoint projects.

It’s very clear from this that people are in one of 3 camps of almost identical size

• Those using Team Foundation Server
• Those that user another non Microsoft tool
• Those that don’t do anything

Team Foundation Server

Installing and using, or developing against Microsoft SharePoint Server requires a fairly big commitment to the Microsoft technology stack, so the domination of Team Foundation Server is probably to be expected.

• If your a big corporate user of SharePoint you most likely have a deal that includes TFS licenses
• You have likely committed to Microsoft as the platform of choice across the board
• If your a Microsoft Partner delivering products and solutions you will have a big investment in Microsoft licenses, and also a duty to adopt the MS recommended path
• TFS is a good solution,  and it’s getting better in 2010

Non Microsoft Tools

I was surprised by the mix of Non Microsoft tools,  having looked at what you get for free and the costs for licensing beyond that I would have expected Team City to have a bigger following.  Perhaps the reason for not being higher is jetBrains being thought of a Java based?

I bundled CruiseControl and Cruise together,  in hindsight I should have split them as they are totally different products.   I will make the assumption that most are using CruiseControl as this was really one of the first decent automated build tools to target the .Net platform.  People have got to know it an have scripted automation for their non SharePoint projects already.

Final Builder I have always liked the look of;  I really do find the whole raw XML editing that we have to do in any build automation a bit like developing against SharePoint,  it’s ok but the tools really should be better than this.   Final Builder has a great product, but the cost per user is perhaps the barrier here.

Other

Some people had build servers but didn’t use it for SharePoint – would really count those as None.

Others listed the source repository (SVN) or scripting language (msbuild, nant) so I assume that the build is done manually using batch files rather than via a dedicated build server.

Also someone listed Hudson,  something I had personally never heard of, but will bundle with the Non Microsoft Tools.

None, we don’t have a build server

This was probably the biggest surprise to me,  and perhaps not the way you might think.  I was actually surprised that only 35% of people indicated that they did not have any form of build server for their SharePoint projects.  

Based on my years of doing consultancy gigs I found that the majority of companies that I went into to do work didn’t have anything even close to an automated build server.  Heck some don’t even have source control for the code!

So I can take a couple of things from this

• People who don’t were too embarrassed to answer
• SharePoint development has moved on significantly and most teams now have proper build servers
• The readers of my blog are not representative of the wider SharePoint user base

Conclusion

There are still a lot of SharePoint teams out there that have yet to get the benefit from automating their builds,  who will undoubtedly be spending many hours manually putting things together the night before Go-Live.  

For these people, and those moving into SharePoint for the first time, there is a need to provide more information on why investing time in getting your automated build in from the start can make huge savings over the life of a project.  Providing walkthroughs on how to do this and some of the challenges you will encounter along the way.

Based on the feedback I could look at doing TFS first,  but I know that for teams with nothing setup yet this is going to be a big stumbling block.  Trying to convince you boss to roll out Team Foundation Server just so you can automate your SharePoint build is not an easy argument to have.   I will instead look at the options allowing you to get up and running quickly and more importantly without needing to get budget for licenses. 

I will start with Cruise,  and I will be dog fooding this for real on Project Aberdovey.  

Thanks to everyone who took the time to vote,  I would love to hear your own take on what the numbers mean to you and your experience with automating builds in SharePoint.

I am looking to provide some guidance on doing Continuous Integration (CI) on SharePoint projects,  looking at the concepts behind CI but also looking to provide examples that can help people get the most out of CI on a SharePoint project.   Having used a number of technologies in the past I thought it would be useful to get an idea of the which technologies people are using, if any. 

Please take a few seconds to tell me what you have used, and have a look at what others are doing.  

I have made the selections mutiple choice as I know people, especially consultants, have worked with more than one platform.  And if you haved used something not listed please add it in the other box.  

Also if you have any specific areas that you would like to see covered please add a comment.

Thanks for taking part