Unit testing is a tenet of Extreme Programming, one of the underpinnings of agile software development practices. Yet, according to several experts, a surprising number of developers still are not doing it.
For developers writing SharePoint applications, there are fundamental impediments to unit testing. First, according to Critical Path Training consultant Andrew Connell, it requires developers to have a live SharePoint instance on their machines, because custom code “will inevitably use something from the SharePoint API that doesn’t work in an offline mode, per se.” This is a problem in developing for any platform that requires a full instance to test against, such as Windows Azure, Microsoft CRM, Salesforce and other enterprise platforms.
The way to address this problem is through mocking, or faking, the necessary piece to complete the test, Connell explained. The mocking framework essentially hijacks the real call and rewires it to do something else, so a running instance of SharePoint is not required.
There are commercial solutions available, such as Typemock’s Isolator, as well as Moles, a Microsoft Research project. Typemock’s solution mocks up SharePoint objects such as SPSites for site collections, SPWebs for sites, SPLists for lists, or SPListItems for items, among others. Eli Lopian, founder and CEO of Typemock, hopes the tool will encourage developers to do unit testing.
“Developers write code and send it off to QA, which runs some regression tests, and the code ping-pongs between IT and QA,” Lopian said. “Unit testing is hard to practice, and that is coupled with pressure to get software out the door quickly.” As more organizations move to agile development practices, though, he believes unit testing will become more routine.
—David
