In November, Microsoft released the SharePoint Guidance document under their patterns & practices section. The idea of centralized best practices for SharePoint is a compelling one as the bulk reference for the platform is based in loose information from various blogs and discussion forums.
After reviewing the document, I felt that some comments and questions were necessary.
List Definition Authoring Tools
The SharePoint Solution Generator from Microsoft has been around for a long time, but I frequently use the CodePlex MOSS Feature Generator which contains many additional features. There are a few issues with the application, most noticeably that any custom content types are incorrectly referenced in the content type reference section within the schema.xml file (as of version 0.7). Still, it's a great tool.
Workflow Implementation
See previous comments on workflow templates and debugging and debugging issues.
Unit Testing, Continuous Integration and Test Driven Development
As said already, there is a lot of discussion around mocking. What I feel is missing is a general overview of unit testing as mocking is primarily used for Test Driven Development (TDD).
Many developers come from a background where web parts and SharePoint features are thrown together quickly and without any test plans, UATs, integration testing or regression testing. To go directly to mocking and TDD might be both overkill and too steep a learning curve.
First we need to ensure that our code is written to support TDD and unit testing by making isolated compartments of code that can be tested using some sort of interface and that method arguments are properly validated. This is basic object orientation and code practice, but I frequently see "spaghetti code" used within SharePoint development, such as web user controls exposed publicly within controls.
Personally, I would ideally like to see TDD used for unit tests, ensure adequate code coverage of all unit tests (I use NCover), automated browser tests and unit tests for regression testing (I use the WatIN framework to create automated browser tests) that attempt to complete each step of the UAT tests and manual testing of all UATs and definitions of done/conditions of acceptance.
Apart from that, all tests needs to be continuously reviewed in order to detect new defects and integration issues. The Team Foundation Server integration build, as mentioned under continuous integration in the document, could take care of this, but it would not be enough to build the solution and run the mock tests.
In a current project, I wrote a continuous integration extension for Team Foundation Server and SharePoint that automatically
- Retracts and deploys the latest build of the feature(s) across a separate test farm
- Recreates the site collection using the latest site definition
- Runs all unit tests and regression tests and copies the report to the TFS build drop folder
- Compiles the SandCastle documentation file for all projects within the solution
- Puts the solution file (wsp), the setup files and the documentation to a sub folder in the TFS drop folder that can be accessible via secure FTP
This approach gives a more complete test plan than using mocking on its own.
Feedback
Please submit any additional comments and feedback on either the document or my comments below. It is important for the community to respond to this document in order for it to evolve!
