Test Driven Development is an essential process to make quality IT products by forcing us to test every requirement of the project. But how can we work with Test Driven Development for SharePoint projects?
Type mocking is a must
There are some issues that makes difficult to go TDD in SharePoint. As Eric Schupps explains in his post. Issues like the time invested in learning how to do TDD in an efficient way, the amount of code needed to do the tests could be a lot more bigger than the method that are testing, etc. But one of the most important issues is that the test methods don’t know anything about SharePoint’s API, so there is no way to test the results of operation made on SharePoint objects like SPList, SPWeb and SPListItem. We need to use mock objects to simulate them. To solve that problem there is a third-party called Typemock Isolator for SharePoint, but can we be 100% sure that TypeMock has created a full collection of mock objects that simulates every single functionality that SharePoint API provides? I’m thinking about permissions or search functionality for example.
Another point of view is what Paul Hunt brings to us here maybe this methodology is useful for largest projects with many logical methods but SharePoint is a web based system where the GUI is one of the more important things and it can’t be tested. Hence we cannot guarantee a code 100% covered with TDD.
Test Driven Development was not designed for developments on platforms like SharePoint
To make the most of Test Driven Development with SharePoint development projects, it is convenient to split the code as much as possible in order to have all code related to SharePoint object in separated classes and perform most of the unit tests on the rest of the code.
In my opinion, and unfortunately, most of the tests cannot be automatized, as mocking SharePoint objects is not 100% reliable, and we will have to do «old school» test 😉