Share Point Development With Unit Testing
•Download as PPTX, PDF•
1 like•638 views
This document discusses unit testing for SharePoint development. It outlines three main goals of unit testing: to run quickly, run on every developer machine with minimal configuration, and not test Microsoft code. It describes where unit testing can be done in SharePoint, such as web parts and event receivers. The document discusses challenges of unit testing SharePoint code due to tightly coupled code and sealed classes. It provides examples of approaches like mocking, wrappers, repositories, and MVP to enable unit testing. Finally, it emphasizes that unit testing helps with refactoring, catching errors from other developers, and reducing environment dependencies, but does not replace writing high quality code.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Share Point Development With Unit Testing
Similar to Share Point Development With Unit Testing (20)
More from Jeremy Thake
More from Jeremy Thake (20)
Recently uploaded
Recently uploaded (20)
Share Point Development With Unit Testing
- 1. SharePoint Development with Unit Testing JEREMY THAKE
- 2. OBJECTIVES To explain the 3 goals of unit testing To explain where you can unit test To describe the 3 approaches to unit testing in SharePoint
- 3. Unit Testing Run quickly Run on every developer machine Minimal no config (We are not testing MS code)
- 4. Where to test? ASP.NET Web Forms Application Pages Web Parts Event Receivers Feature Receivers Workflow coding activities Timer Jobs
- 6. UNIT TEST 101 SETUP
- 8. SharePoint + Mocking Interfaces are rarely used Sealed classes Internal Constructors TypeMockIsolator for SharePoint
- 9. MOCKING 101
- 10. NATURAL MOCKS
- 13. REPOSITORY
- 14. MVP – Model View Presenter
- 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
- 16. MOCKING LARGE AREAS OF SHAREPOINT
- 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()
- 18. JEREMY THAKE http://wss.made4the.net @jthake
Editor's Notes
- 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>