"Test Driven" SharePoint Development

Last month I posted an argument for a Developer Edition of Office SharePoint Server. By no means was this a wholly original or new idea, but some of the benefits of such a product were being poorly articulated and it needed some wider exposure.

Anyways, the original post generated some good discussion both here and elsewhere and the general consensus is that people want it. Over the last few days the post has been re-invigorated, and Andrew Woodward commented about an associated topic, the lack of SDL approaches to SharePoint development in general.

Andrew's point on testing and continuous integration actually preempts another post I had in draft regarding "Test Driven SharePoint".

Now I'm not a test driven zealot or expert by any means, but I am an expert on the SDL (or so I'm told, anyone out there know what "expert" actually means? :)) Some of the credit for the ideas herein goes therefore to Adrian Spear, who most certainly is a TDD guru.

Andrew comments:

"...it still doesn't solve the problems we are all facing in trying adopt good development methologies. I would like to get to a position where sharepoint development teams are doing continuous integration and testing!"

Indeed. Well said that man, the number of hacked out SharePoint widgets I've seen is outrageous, and the quality in general is oh so poor. This is fine for some little partner dev shop building single server solutions for Mickey mouse clients. Enterprises however, who increasingly run portions of their business on SharePoint shouldn't be forced to accept this situation.

Now don't get me wrong, this is generalization. There are quality ISVs and "Gold Partners" out there doing a decent job, but they are the minority rather than the majority. Even some well known WebPart vendors still ship installers that slap stuff into the GAC because they are lazy. You know who you are and you know you gotta fix it!

In order for SharePoint to become a true enterprise application development platform, and for the SharePoint development community to reach critical mass, the quality of skills and output must be raised significantly and quickly. One of the ways to achieve this is to implement Software Development Lifecycle approaches - rather than hacking out widgets based on sample code. But of course, this isn't just a SharePoint problem, as Andrew articulates:

"some (or most) asp.net development teams have yet to reach this and the tools are already out for this."

So with plenty of decent TDD frameworks and utilities and guidance out there, the ASP.NET world is slow to adopt. This is true of Web development in general of course, because to a certain degree things like ASP, ASP.NET and PHP have made it "too easy" to build solutions, which based on appearances alone are no different that quality software. If ASP.NET dudes are slow to adopt, what hope for the SharePoint gals?

Let's be clear - there are limitations with the SharePoint Platform and Tools which make real SDL approaches difficult. You will see folk blog or write articles on how they work around these issues, and none of them are particularly nice. They work, but not as seamlessly as they should. Can anyone say TFS integration? : ) But remember, tooling only supports process or methodology (or mythology as I've been known to call it!), and a poor workman blames his tools.

Well, it turns out that it's up to the community to raise the bar and start offering solid, practical guidance. Guess what? - the same tools you can use for ASP.NET can be used for SharePoint. Consider SPI Dynamics' WebInspect, this is the defacto tool for performing web application vulnerability assessment and remediation with tool integration into Visual Studio and TFS. This product is uber-awesome. Consider the Threat Modeling guidance from P&P to ensure you don't introduce vulns through poor design. Both of these things should be considered prerequisite steps for commercial apps or components. And they both work just great with SharePoint. Indeed, SPI will be releasing additional modules specifically for SharePoint specific attacks over port 80.

All very nice you are thinking but what has this got to do with TDD? Well, the same principle applies.

Here's a mantra for "Test Driven" SharePoint Development:

1. Avoid getting tied up in intellectual pursuits - or codehead techlove for the sake of it - TDD itself is not the art, quality software is.
   Typically, you can achieve everything you need to do to have a clean, testable code base without resorting to exotic means if you just think about what you’re doing before you do it. Following best practices and proven patterns will never let you down.
   
2. Keep your tests simple - KISS baby, KISS - each test should test for one thing and one thing only.
   Follow the red-green-refactor rule and you will also ensure that you eliminate false positives and negatives. It may sound excessive to have reams of tests but if they are developed intelligently they can easily be maintained. Your attention to design should be as acute for your test code as for your production code and include frequent reviews and refactorings where appropriate.
   
3. Invest in a solid mocking library - I'm talking about TypeMock.
   One of the often heard complaints about TDD in the SharePoint world is the inability to mock concrete classes (such as HttpContext). TypeMock allows this, something the competition cannot.
   
4. Consider your approach to contextualised objects rationally.
   A related moan is how to test parts of the solution which referenced contextualised objects from the http, MCMS or SharePoint "frameworks" – for example, the template code-behinds and custom navigation, and authoring and presentation web controls in MCMS or the context, navigation and ContentPlaceholder controls in SharePoint. Naturally, when these objects are being tested with the framework of NUnit or VS there is no context within which to run and they will fail.

Some folks have suggested approaching this by producing interfaced wrappers for the contextual objects and mocking the interfaces in the test code. This is utterly horrible, and is codehead-ness to the extreme. Such an approach adds complexity to your production code to ease your test code implementation, unnecessarily complicating your design pattern. With TypeMock it is possible to create typed mocks which can mock any concrete classes (including private, protected and internal methods, properties etc) and eliminate such elaborate mechanisms.

 

So there you have it - a first stab at providing some guidance for those looking to implement SDL approaches to SharePoint, and a call to action for the developer community to adopt "Test Driven" SharePoint development.

Finally, all of the above is applicable to VS 2003 with NUnit  for .Net 1.1 or VS 2005 Test (or even NUnit for .Net 2.0) as the unit testing framework. Oh and did I already mention you should go out right now and buy TypeMock? At $299 per codehead you know it makes sense.

Please comment here if you have more to add or just plain hate it :) I will be expanding on SharePoint SDL topics over the next few months.