Since last few years developer and architects are more talking about the value of Agile and Test Driven Development (TDD). As we see more and more SharePoint projects are developed using Agile but somehow TDD not fairly recognized but SharePoint is different. It need some up-front architecture decisions, certain types of artifact very difficult to back out once in production (e.g. list schema). Tight integration with the underlying platform can make code inherently difficult to test because there is a big black box SharePoint object model involved. In this presentation and demo, want to explain tricks, mocking tools and challenges to implement TDD to an extent and get benefits of TDD.

1. ABOUT MYSELF
Solutions Principal with Slalom Consulting
(SharePoint Consulting Practice) having more
than 10 years’ experience in system analysis,
architecture, development and deployment of
state-of-the-art IT solutions, working for diverse
set of clients, including several of the largest
financial institutions and supply management
verticals in the US on Microsoft platform, with
particular focus on implementing collaborative
portal solutions utilizing SharePoint Products
and Technologies.
Do not Follow Me : @SanjivKSharma

2. NEW JERSEY SHAREPOINT USER GROUP
• Different SharePoint discussions each
month on various topics. Announced on
meetup.com
• Meets 4th Tuesday of every month
• 6pm – 8pm
• Microsoft Office (MetroPark)
• 101 Wood Ave, Iselin, NJ 08830
• http://www.njspug.com

3. THANK YOU
EVENT SPONSORS
• Diamond & Platinum sponsors
have tables here in the Fireside
Lounge
• Please visit them and inquire
about their products & services
• Also to be eligible for prizes make
sure to get your bingo card
stamped

4. • What is TDD – Intro and Misguided
• Challenges with SharePoint
• Unit Test against SharePoint – How ?
• Tool Required to Implement
• Demo
• Pros and Cons - Conclusion

5. Test-driven development (TDD) is a software
development process that relies on the repetition of a
very short development cycle:
• First the developer writes an (initially failing)
automated test case that defines a desired
improvement or new function,
• Then produces the minimum amount of code to pass
that test, and
• Finally refactors the new code to acceptable standards

6. • Red: Starting with a test, the test is red, because the
production code doesn’t even exist
• Green: From developing the test, it is clear what classes,
fields and methods are required to satisfy the test.
Production code is implemented until the test is green.
Only the minimal implementation that turns the Unit
Test to green shall be produced! No overhead code.
• Refactor: After the expectations, expressed through the
test have been met by the code, it is time to refactor and
apply the “Software Engineering Principles”

7. Uncle Bob describing Test Driven Development in terms of
three simple rules. They are:
1. You are not allowed to write any production code unless
it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than
is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code
than is sufficient to pass the one failing unit test.
(http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd)

8. • No enough time to write the tests.
• Testing isn’t my job, because …………..
• Unit tests don’t help me, because …………..
• There’s no need to test drive my code, because …………..
• Running the tests is a pain, because …………..
• I don’t like TDD, because …………..
• TDD sucks because …………..

9. This is a short (and certainly not complete) list of the
benefits of TDD?
• Minimizing the debugging time
• Less bugs Better productivity
• Improved code quality and confidence
• Enables future enhancement by ensuring existing
functionality is maintained (tests)
• Enforces loose-coupling
• Any finally … Code is always working 

10. • Need some up-front architecture decisions, certain types of artefact
very difficult to back out once in production (e.g. list schema)
• Tight integration with the underlying platform can make code
inherently difficult to test

11. • Ready-Only Mentality
• Most of the SharePoint API does not implement any interface
Example:
public static SPSite GetSiteObject(string url)
{
//Option 1 - New Object
return new SPSite(url);
//Option 2 - From Current Context
return SPContext.Current.Site;
}

12. • Can be difficult to maintain discipline under pressure
• Difficult in brownfield development
• Difficult without management support

13. The usual suggestions provided by various MVPs:
• Use the Model-View-Presenter (MVP) pattern to isolate your business logic
from the user interface and the data source.
• Implement interfaces for your view classes and your services (such as
repository classes).
• Can also use the Service Locator pattern to decouple your presenter class
from specific implementations of the services that your presenter uses
(such as your repository class).
• Also you can use the any mocking framework to replace the calls to the
SharePoint Object Model.
• Some also have suggested to use a local installation of SharePoint,
populate it with test data, and unit test against it.

14. Mocking Frameworks for SharePoint Development
• TypeMock : Mocks sealed objects, static methods and internal constructors
- required to access various SharePoint Objects
Easy to learn, author and maintain API.
Intuitive AAA (Arrange-Act-Assert) API.
Professional customer support
The price
• Microsoft Fake (previously known as Microsoft Mole) : Mocks sealed
objects and internal constructors - required to access various SharePoint
Objects.
Intuitive authoring with Behaved Types –
Available on in VS Premium (in addition to Ultimate).
For more info : http://blogs.msdn.com/b/bharry/archive/2013/01/30/announcing-visual-studio-2012-
update-2-vs2012-2.aspx

17. SharePoint Timer Job:
1.Get the Items from list where the “EmailDate” is less than
today date.
2.If the Retention Status is Email1/Email2  Send Email only
3.If the Retention Status is "Archive"
a.Send Final Email.
b.Perform action on the document to delete or archive based
on some metadata flag on some document property.

18. Pros:
We have already discussed some benefits of the TDD, but
Cons:
• Lots of plumbing - More code and complex project structures
• Negative and Positive - how far to go with this is hard to define e.g tests for
invalid urls
• People only test code they know works
• People tend to use it as integration test rather than discrete unit tests
• Bug learning Curve

19. Business Facing
Technology Facing
Supporting
Team
Critique Product
Functional Tests
Examples
Story Tests
Prototypes
Stimulation
Unit Tests
Components Test
Exploratory Tests
Scenarios
Usability Test
User Acceptance Testing
Alpha/Beta
Performance and Load Testing
Security Testing