15. What to test? TDD - lots of code when 80% is usually SharePoint code Tests functionality and requirements work Can cover scenarios and edge cases Missing or empty URL variable Valid URL variable syntax Existence of the specified site Missing or empty ListName variable Existence of the specified list Valid SPListItemCollection return object Null or empty SPListItemCollection return object
17. CONCLUSION It not easy “Lots of code” Benefits when refactoring other developers changing it environment dependencies reduced speed Doesn't stop poor quality code: list.Items.Count Dispose()
Where – web parts, asp.net forms, event receivers, feature receivers, workflow, timer jobsApproaches – wrappers/facades, repositories, mocking
Spiking - Use PowerShell!Integration TestsWeb Tests
VMReflectorWSPBuilderVisual Studio 2008MOSS 2007 IUSQL 2008Create new WSPBuilder ProjectCreate new Feature ReceiverCreate new Unit Test ProjectAdd references: Nunit, SharePoint, Typemock, WSPBuilder ProjectAdd using statementsShow ReSharper, NunitAct | arrange | assert
Interfaces are rarely used: If our code that depends on an SPWeb could instead depend on an ISPWeb interface (assuming that SPWeb implemented ISPWeb), we could easily create a mock implementation of ISPWeb. We could pass our mock into our code instead of an SPWeb. We could define the exact behavior of the mock. However, since SharePoint elements such as SPWeb, SPList, and SPItemEventProperties don’t implement public interfaces, this is not an option.Sealed classes: The SharePoint elements mentioned above are also sealed. Another mocking technique is to extend the type you want to mock overriding all the base class’s methods. Instances of the mock type can be substituted for the instances of the base type. However, since many SharePoint elements including the ones mentioned above are sealed, this technique is also not an option.Internal Constructor: SPWeb Even if there were no behavior in our dependent service that we need to override, we still would need to create an instance of it. Again, many SharePoint elements including the ones mentioned above have internal constructors so we are not expected to new up our instances, but rather get them for calling the SharePoint API.Collections with no Add method: Many of the collections provided by SharePoint such as SPItemEventDataCollection do not have a public Add method. This makes it difficult to mock if we can’t populate an instance of this collection with a controlled set of values. Pasted from <http://blogs.msdn.com/francischeung/archive/2008/08/22/unit-testing-sharepoint-2007-applications.aspx>
Demo FeatureReceiver1 thru FeatureReceiver4
Add try catch to check site not found, when passed in to see whether app code handles it
Wrapping everything with repository model
Another option is to provide an abstraction to the SharePoint API that can be mocked. A wrapper is an abstraction that provides a mirror of the SharePoint API. Pasted from <http://blogs.msdn.com/francischeung/archive/2008/08/22/unit-testing-sharepoint-2007-applications.aspx> A façade is an abstraction that simplifies the SharePoint API. Either approach takes a lot of work and may be very difficult to do well. Pasted from <http://blogs.msdn.com/francischeung/archive/2008/08/22/unit-testing-sharepoint-2007-applications.aspx>