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.

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.

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.

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

Along the way almost everyone I talked to understands the basic idea that the earlier in the cycle you find a defect the cheaper and easier it is to fix, and from this most (if not all) agree that Unit Testing is one of the most cost effective ways to catch these defects. The problem is, it appears, developers are lazy; they understand they should do it they just never get around to it – ‘perhaps on the next project’.

As part of my own development I like to work with, be trained by or just hang with people that I see as having reached a higher level of knowledge and skill than me in a particular field. You could say a greater Mastery of the subject. One area that I am very passionate about, many may have seen some great interviews on the subject, is Test Driven Development (TDD). TDD is more than just doing Unit Testing; it is a technique that once you understand and are willing to invest time in helps you to become a better developer.

I have been doing TDD, although not on every project (sadly), for about 2 years and have shared the knowledge I have gained through white papers, blogs and talking at conferences. In trying to lead the way in my area of expertise, SharePoint, I felt that I was missing something. I had yet to reach a place where I felt that I had mastered the art, where I had moved into the phase of challenging myself to do more than just the practice of TDD.

As part of my work with Typemock, the only solution of working with SharePoint’s sealed API, I found that these guys really did get it, they had the battle scars and were practicing what they preached, and they were challenging themselves to do it different, better. Roy Osherove is the Chief Architect at Typemock and I have seen him speak at conferences in a way that was engaging and thought provoking. The opportunity therefore to be able to spend 5 days with Roy doing a TDD Master Class was one that I could not miss.

I’m not going to do the, on day 1 we did this, on day two we did this, as I think that Sara (fellow attendee) has covered this quite well in her post. Instead I will talk about how the course was much more than a lesson in Test Driven Development; we paired up to cover all of the practices looking at the basics of unit testing frameworks (Nunit, MSTest), understanding isolation frameworks (Moq, Rhino Mocks, Typemock Isolator) and how they all look to solve the same issues whilst using slightly different syntax. We looked at how the techniques around TDD have evolved over time, and the how the tools have really moved on significantly in recent years making the barrier to entry and the ability to create readable and maintainable code possible. We looked at techniques, like the daily Kata, that will help perfect the practices, and discussed the ideas of Shu -Ha -Ri where the student moves from the fundamental techniques, to finding new ways and challenging tradition and then onto surpass the teacher and ultimate mastery.

I liked the way Roy questioned the idea that the lazy coder was in fact the one looking to do it as easily as possible, the one who knew all of the keyboard short cuts, the one with all the Live Templates in ReSharper. The Lazy code is really the one who gets the job done well, with the least amount of effort – unlike the average developer, who I initially thought of as lazy, who just doesn’t see development as a craft but more a way to pay the bills.

My view that learning from someone, who is at a higher level of knowledge and understanding has been reaffirmed. The same principles should apply to you, when you look at training and work, ensure that the person teaching you is someone you admire, someone who you feel has the level of knowledge and experience that you aspire to.

Having attended Roy’s TDD Master Class I can say that my knowledge has been enhanced, the core values have been reaffirmed and I am now in a much better place with regards my own capability, but more importantly my own ability to help others.

So the question is should you attend Roy’s TDD Master Class?

If you want to really Master the Art of Test Driven Development then definitely.