Upload
edin-kapic
View
128
Download
3
Tags:
Embed Size (px)
DESCRIPTION
My slides from the session on SharePoint Saturday Belgium 2014
Citation preview
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