Your SlideShare is downloading. ×
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Share Point Development With Unit Testing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Share Point Development With Unit Testing

1,031

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,031
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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>
  • Transcript

    • 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
    • 5. WHAT ITS NOT!
    • 6. UNIT TEST 101 SETUP
    • 7. TIGHTLY COUPLED CODE
    • 8. SharePoint + Mocking
      Interfaces are rarely used
      Sealed classes
      Internal Constructors
      TypeMockIsolator for SharePoint
    • 9. MOCKING 101
    • 10. NATURAL MOCKS
    • 11. SharePoint Guidance
    • 12. WRAPPERS & façades
    • 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&apos;t stop poor quality code:
      list.Items.Count
      Dispose()
    • 18. JEREMY THAKE
      http://wss.made4the.net
      @jthake

    ×