• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Share Point Development With Unit Testing
 

Share Point Development With Unit Testing

on

  • 1,670 views

 

Statistics

Views

Total Views
1,670
Views on SlideShare
1,657
Embed Views
13

Actions

Likes
1
Downloads
22
Comments
0

3 Embeds 13

http://www.linkedin.com 8
http://www.slideshare.net 4
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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
  • 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 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

Share Point Development With Unit Testing Share Point Development With Unit Testing Presentation Transcript

  • SharePoint Development with Unit Testing
    JEREMY THAKE
  • 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
  • Unit Testing
    Run quickly
    Run on every developer machine
    Minimal no config
    (We are not testing MS code)
  • Where to test?
    ASP.NET Web Forms
    Application Pages
    Web Parts
    Event Receivers
    Feature Receivers
    Workflow coding activities
    Timer Jobs
  • WHAT ITS NOT!
  • UNIT TEST 101 SETUP
  • TIGHTLY COUPLED CODE
  • SharePoint + Mocking
    Interfaces are rarely used
    Sealed classes
    Internal Constructors
    TypeMockIsolator for SharePoint
  • MOCKING 101
  • NATURAL MOCKS
  • SharePoint Guidance
  • WRAPPERS & façades
  • REPOSITORY
  • MVP – Model View Presenter
  • 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
  • MOCKING LARGE AREAS OF SHAREPOINT
  • 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()
  • JEREMY THAKE
    http://wss.made4the.net
    @jthake