SharePoint TDD Series: Maintainability over Ease
This series is part of my wider initiative around the Test Automation Pyramid. Previously I have written around Asp.Net MVC. This series will outline a layered code and test strategy in SharePoint.
SharePoint is a large and powerful system. It can cause problems in the enterprise environment incurring delays, cost and general frustration. Below is an overview of the main areas of innovation made in the source code to mitigate these problems. These problems are because the fundamental design of SharePoint is to design an “easy” system to code. It is easy in this sense is a system that can be configured up by general pool of developers and non-developers a like. Such a design however does not necessarily make the system maintainable. Extension, testability and stability may all suffer. In enterprise environments these last qualities are equally if not more important to the long-term value of software.
This series of posts outlines both the code used and the reasons behind it usage. As such it is a work in progress that will need to be referred to and updated as the code base itself changes.
Deployment Changes
- SharePoint Installations: Strategy to aid continuous integration
- deployment packaging
- scripted deployments
- migrations – versioning configuration through environments using migratordotnet for SharePoint – code on GitHub
- deployments from TFS/Windows Workflow via hosted WCF/Windows Workflow service
Layered Code with testing
Testing on Event Receiver via declarative attributes
- Part 1 – Testing with Poor Layering in not good TDD
- Part 2 – Good layering to aid testability
- Part 3 – Event Receiver as procedural, untestable feature
- Part 4 – Event Receiver as layered feature
Testing Delegate controls which deploy jQuery
- Part 5 – Client side strategies for javascript
- Part 6 – Unit testing the jQuery client-side code without deploying to SharePoint
- Part 2 – Unit testing the delegate control that houses the jQuery
- Part 4 – Exploratory testing without automation is probably good enough
Cross-cutting concerns abstractions
- integration testing on permissions model
- logging with service locator
- centralised configuration store that represents site relationships
- Part 7 – Using a repository pattern to return domain concepts that we use to encapsulate SharePoint technical implementations