Agile Sharepoint development by 21apps and Andrew Woodward MVP

Another great day for SharePoint developers.   Typemock have announced the introduction of Isolator for SharePoint.

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.

Great panel session at PDC on the future of Unit Testing. There were some good discussions by some ‘luminaries’ in the field (Peter Provost, Daniel Cazulino and others) that really talked more about where we are today than about where we are going in the future. Some of the biggest things I took from the session.

What is a Unit Test

People still don’t understand what a Unit Test is.  There were questions on complication on testing components, testing databases, testing WCF.  It shows that we have issues around not just unit testing but around testing in general the tools for integration and acceptance test are still lacking.

As with other aspects of development we are lacking the DSL (Domain Specific Language) and tools to make this work,  Unit Testing is probably in the best place.

Mocking – For and Against

There is a big split between those that like Mock frameworks and those that dont, in fact there wasn’t really a big split.  Peter Provost doesn’t like them, they encourage bad design, they let you get away with too much – I agree with Peter on this, however you don’t have an option in lots of situations.  I do not have the ability to refactor the framework I develop on as it’s written by Microsoft and called SharePoint.  Until the frameworks are refactored we need to use mocks – most of the audiance seemed to be in this camp.

Daniel Cazulino argued the case that using a framework to do your mocking and stubbing was good, people got too hung up on the mocking when actually most people just stub out methods using the framework, much the same as you would do manually if coded the waty Peter wants.

Some Futures

Not really that far in the future,  Microsoft Research have released Pex a system to automate whitebox testing.  I can see this having real bog value in situations where you have lots of legacy (existing) code that you can’t afford to refactor/rework.

The challenges of concurrency with the preverlance of multi-core systems and the improvements in tools to make coding easier.

TypeMock have recently made some updates to their site and have started to pull together information around testing SharePoint. I’m really getting to like the new AAA (Arrange, Act, Assert) approach that they are building into the product from version 5 onwards.

 Gil Zilberfeld post a great example of this by refactoring the work that was done on the SharePoint Patterns and Practices project using the (coming very soon update to TypeMock).   Although I like Natural Mocks it tended to make the tests quite long and very brittle, using the new AAA syntax this becomes so much more cleaner.

Members.ReturnRecursiveFakes seems to be where all the magic exists.    Previously you would have to write stub code for everything your method touched on the objects, which made the tests very brittle, now using the Recursive Fakes approach you only need to stub out the methods that you want to validate.

Roy Osherove manages to explain this in a very easy to understand way.

The Patterns & Practices group are looking at Guidance on SharePoint and are making regular code drops to the CodePlex project.

They have done research and the customers have ranked the requirements in order of importance.

Who would have thought Unit testing and debugging would have been top of the list!

Francis Cheung is on the P&P team for SharePoint Guidance and has posted some of the details from their work to date,  you will see a very good review of the reasons unit testing SharePoint is hard and also some explanation behind the design decisions taken in the sample project on CodePlex.   Some of the areas hi-lighted will be covered in more detail in our more advanced white papers.

TypeMock Video

I also spotted a little nugget comment on the post pointing to a short (9min) video on using TypeMock for SharePoint,  you have to question the TDD approach in the demo but I don’t think this is the aim.  It uses Natural Mocks and explains the difference between recording and the creation of mock objects, the use of RepeatAlways() to create a Stub and a few other simple tips.

For those new to TypeMock there are 4 other videos that will give you more details,  we will be covering the use of TypeMock in our more advanced white papers.

We are very pleased to announce the publication of our white paper Beginners Guide to Test Driven Web Part Development.

This white paper forms part of our Unit Testing SharePoint Solutions – The Basics series and provides an introduction to unit testing web parts within SharePoint 2007; this is a beginner’s guide and as such does not aim to address some of the more challenging issues you will face as you develop your SharePoint solutions (we will be covering these in our future more advanced white papers) but aims to get you thinking about how to develop with testability in mind.

We start with a common user story and walk you through the development of the functionality adopting a Test Driven approach. We introduce some of the tools and frameworks we use to help us adopt a TDD approach and look at where we feel the border between Unit and Integration testing exists.

This white paper is based on our views and experience, we welcome your comments and suggestions and will update the white paper as the community knowledge, experience and best practice evolves.

I would like to thank Spence Harbar and James Fisk for reviewing this paper.

Spender Harber posted a recent article “Test Driven” SharePoint Development

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

I’m in, anyone else?