This retreat, organised by Paul Beck, is looking at two areas LINQ to SharePoint and InfoPath.

The other brilliant thing about SharePoint Retreats is they are completely free to attend community events – this does mean that the places even on a Saturday get filled very quickly.

For more information on the event and to register visit the Eventbright listing.

Happy SPRetreating

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 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.

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.

In this article and screen cast we will discuss the idea behind the CI process and focus on the technical tricks that we need to make in order to get this working for a SharePoint 2010 project using Team City and Subversion.

One of the first things that you will want to do for any development project is setup your Continuous Integrationprocess. The value of having a server automatically monitor your source code repository for changes and validating they work is immense

Its worth mentioning that doing Continuous Integration is not something you will want to leave until later in the project.  Waiting means the solution gets bigger and more complex which in turn make the setup more comples.   My recommendation:  Get this configured early, during Sprint 0  (i.e. before you write any real production code) if at all possible.

The basic CI Process

The diagram below shows the normal process that occurs.  

(1) a developer checks in some code changes to the source code repository.

(2) The CI server monitors the source code repository for any changes

When changes are detected the code is retrieved and the automated build is started.  This build will normally include running Unit, Integration and Build Verification tests.

(3) The success or failure of the automated build is reported back to the Team (including the developer).

In some teams breaking the build means the developer has a forfeit of some sort.  The idea is to encourage team work but also to discourage broken builds.

When the build breaks!

A term I read recently, ‘Stop-the-Line’,  is used in Toyota manufacturing process where any problem results in the production line being stopped until the cause of the problem is found, resolved and ideally prevented from re-occurring.    

This should be the same when a build breaks; the whole Team should stop and help get the build working again.  It is not just a problem for the developer who last checked in – the whole team need the process and need the builds to be working.

Setting Up in Sprint 0

The actual process described above is a little into the development cycle, when the build is in place and when the team are working on production code.   Before this can happen there needs to be a process put in place.  I refer to this initial as getting the strawman solution done.

definition: Strawman

In general, a strawman is an object, document, person, or argument that temporarily stands in for and is intended to be “knocked down” by something more substantial.    

source: Whatis.com

The aim is to take some code, which will be replaced hence the Strawman term through the CI process and get the team build notifications working.   You should aim to prove the successful builds but also what happens when the build fails.  Did the team get notified?  and did they react?

The Strawman Exercise

21apps is a small and geographically dispersed team,  we make extensive use of cloud based services for things like source control as they prove to be cost effective and flexible and our strawman  process tends to follow these steps:

1) Create a repository for the project  (Hosted Subversion)

2) Create the strawman project  (Simple ‘hello world’ web part)

3) Create a simple build script  – small steps mean a successful compile is our objective

4) Create a automated build configuration on our CI server – we use Team City

5) Prove the successful and failed builds

In this post we are focusing on step (4) setting up Team City as our CI server. 

To make this easier I have provided a quick video walkthrough on what we have done for the early builds of Project Aberdovey- the process will be very similar for your SharePoint 2010 solutions.

SharePoint 2010 – CI with TeamCity from Andrew Woodward on Vimeo.

Video Spotlights

Key areas that are highlighted in the video that you will enable you to build SharePoint 2010 projects in Team City.

If you are using MSBuild ensure you set the MSBuild version to Microsoft.Net Framework 3.5 and x64 run platform.

Force Team City to use MSBuild 4.0 as this is needed by adding the Environment Variable

Name: MSBuild

Reference Syntax: %env.MSBuild%

Value: %system.DotNetFramework4.0_x86_Path%

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.

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

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.