Maintainable Testable SharePoint Components SPSBE 2014

How to Build Maintainable and Testable Custom SharePoint Components#SPSBE24Edin KapićApril 26th, 2014

Thanks to our sponsors!

Gold

Silver

Works for Beezy in Barcelona, Spain

President of Catalonian SharePoint User Group (SUG.CAT)

Geek, sailor, philosopher

sug.cat

Ik vraag me af of dit bier

compatibel is met SharePint

@ekapicwww.edinkapic.com

Edin Kapić

Introduction

SharePoint code should be...

Deployment structure

Code structure

Source code management

Unit testing SharePoint

Agenda for today

Maintainable

Testable

Deployment structure

Deployment structure “How the solution pieces will be deployed to SharePoint”

Monolithic WSP Shared WSP + Feature WSPs Framework WSP + Shared WSPs + Feature WSPs

Monolithic WSP

Simpler Retraction of one WSP removes shared libraries from BIN/GACOnly one version path for componentsNot granular enough

MySolution.wsp

Shared WSP + Feature WSPs

Functionality can be separately versioned and managedRetracting one functionality doesn’t break shared libraries

More complexLimited reusability

MySolution.Specific1.wsp

MySolution.Common.wsp

MySolution.Specific2.wsp

Shared WSP + Feature WSPs

Framework + Shared + Feature WSPsCommon SharePoint code can be versioned separatelyMore control over code reuse and management over multiple solutions

Even more complex

MySolution1.Specific1.wsp

MySolution1.Common.wsp

MySolution1.Specific2.wsp

MyFramework.wsp

MySolution2.Specific1.wsp

MySolution2.Common.wsp

MySolution2.Specific2.wsp

Framework + Shared + Feature WSPs

Custom services Can be deployed to various places in SharePoint

Layouts folder ISAPI folder (recommended) Separate IIS site

Code architecture

Code structure “How your VS solutions and projects are organized”

SharePoint project only SharePoint + Library project SharePoint + Multiple library projects Multiple solutions

SharePoint project only Simple Not really flexible

WebParts

SharePoint + Library project Some separation of concerns

WebParts Business

SharePoint + Multiple library projects Recommended for maximum abstraction Don’t overdo the abstraction :-)

WebParts Business Repositories Tests

Multiple solutions Excluding extra projects Reuse projects across solutions

WebParts Business WebParts Business Tests

NoTests Full

Demo: Simple to Complex

Source code management

Source code management Centralized • Distributed

Source code management Centralized • Distributed

“The Truth”

Developer 1

Developer 2

Developer 3 Developer 1

Developer 2

Build Server

Corporate Repository

Branching Standard guidance still applies

ALM Rangers Branching Guidance on CodePlex

Branch whenever you can’t check in yet

With DVCS branching is much easier

Single release branch

Two branches (dev + release)

Feature branches

Unit testing SharePoint

Unit tests

Testing levels Unit

Isolated functionality

Integration Coordinated functionality

Acceptance End-user functionality

Click to insert photo.

Depends on abstractionsSeparates concernsInversion of Control (IoC)Dependency Injection (DI)Repository patternService Locator patternMVP/MVC

Testing-friendly code

Demo: Adding unit testing

Testing strategies Test the coordinating code first (presenters, controllers, business logic) with mock/stub/fake dependencies

Test the concrete repositories (the ones that hit SharePoint or a database) apart

Don’t forget your CUT

SharePoint “quirks” with unit testing SP* objects have no interfaces, are sealed or have no public constructors You can use SharePoint Emulator or Typemock Isolator to get around

it But, your “coordinating code” shouldn’t have dependencies on them

IDs of SharePoint objects are not fixed You can’t access SharePoint server OM remotely

Summary

Maintainable, testable SharePoint Decide your deployment and code structure and be consistent

Decentralize source code management for greater flexibility

Add abstractions and IoC/DI to your code, but don’t get lost in it

Test, test, test

Dank jullie wel!Merci beaucoup!

@ekapicwww.edinkapic.co

m