Your SlideShare is downloading. ×
  • Like
SPCA2013 - Test-driven Development with SharePoint 2013 and Visual Studio
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

SPCA2013 - Test-driven Development with SharePoint 2013 and Visual Studio


Test-driven Development with SharePoint 2013 and Visual Studio

Test-driven Development with SharePoint 2013 and Visual Studio

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Test-driven Development with SharePoint 2013 and Visual Studio Bill Ayers
  • 2. MCM/MCSM SharePoint MCTS, MCITP, MCSD, MCAD, MCSA, MCDBA, MCT etc. Professional Scrum Master (PSM I) Consultant currently specialising in SharePoint Development and Architecture for Web Content Management Blog: E-mail: Twitter: @SPDoctor
  • 3. Agenda: Introduction to TDD  Server-side tests  Client-side tests  ATDD  Conclusions 
  • 4. Pre-historic Software Development FORTRAN/COBOL  Wish lists  Ad-hoc development  No source control!  FORMAT statement 
  • 5. Waterfail Requirements Big design up-front  Write-only documentation Design/Arch Coding  Analysis paralysis  Wrong product QA  Over budget/time  Project failure Deployment  Maintenance
  • 6. Agile • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan
  • 7. The patterns and practices tag cloud
  • 8. SharePoint is Different 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 
  • 9. Extreme Programming - XP Test-first development  Pair programming  Refactoring  Continuous integration  Frequent releases  Coding standards  Sustainable pace 
  • 10. What is TDD? Goes beyond Test-first  Tests drive the low-level design  Supports refactoring  Just a developer tool 
  • 11. TDD Cycle requirements write a failing test refactor make test pass
  • 12. TDD rulebook No code unless failing test  Write just enough code to pass test  No new test until green  Refactoring must not add functionality  Tests must be fast  Tests must be easy to run (i.e. automated)  Purpose of test should be clear  Tests should be independent (run in any order)  Test code is a first-class citizen 
  • 13. How does TDD work? TDD is counter-intuitive  Tests facilitate refactoring  Refactoring facilitates incremental design  Failing tests pinpoint problems quickly  Fast (continuous) tests give immediate feedback  Tests should ideally isolate the code you are working on  Rapid feedback  Less bugs 
  • 14. Refactoring Clean up variable and function names for clarity  Make code more concise  Remove spaghetti code  Remove duplicate code  Extract methods to avoid oversize methods  Keep re-running the tests as you re-factor  If test fails then Ctrl-Z, Ctrl-Z, Ctrl-Z … 
  • 15. Shopping List Story
  • 16. Shopping List Story As a team site user  I want my shopping list visible on the home page  So that I don’t forget stuff  Acceptance Criteria: • • • Does a shopping list panel appear on the home page? Does the panel show all items in the shopping list? Are the items sorted alphabetically
  • 17. Demo: TDD – Introduction
  • 18. Benefits of TDD?            Less bugs Better productivity (once the technique is learned) Safe refactoring results in better code design Cleaner design because enforces KISS and YAGNI Improved code quality and confidence Tests document the design Easier to handle interruptions to “flow” Incremental development Test coverage Enables future enhancement by ensuring existing functionality is maintained (tests) Strangely hypnotic, especially if you do it while listening to progressive dance music
  • 19. Drawbacks           Can be difficult to maintain discipline under pressure Difficult in brownfield development Difficult without management support Excessive and trivial tests False sense of security Cost of maintaining tests Not all development is equally suited to TDD Not a silver bullet Not appropriate for spikes or other non-production code Note all code is easy to test (e.g. SharePoint)
  • 20. Types of tests Test type Spee d Unit Requir e Code Acces s Nee d to run on SP Box Suit Sui Sui Suit TD t t Acce D De QA pt v Need Tools Isolatio n f/w FAST * * * * * Integratio n (shallow) MED * * * * MSTest, NUnit Integratio n (deep) SLO W * * * MSTest, NUnit UI SLO W ? Manual GLA CIAL * * * (ATD D) MSTest, NUnit VS (Coded UI), Selenium, Watin
  • 21. Unit tests with SharePoint SSOM – possible approaches (1) Public methods, overrides of virtual methods, etc.  Isolate SharePoint calls within a Repository class  Service Locator pattern – P&P guidance  Composite design patterns e.g. MVC/MVP, + conventional mocks and stubs 
  • 22. Beware: Trivial Test Anti-pattern Presenter: string ShowMessage(string message, string name) { string messageresult = message + “ “ + name; Return messageresult; } View: Void RenderContents(..) { String message = ShowMessage(“Hello, “, SPContext.Current.User.Name); textwriter.write(“<h1>” + message + “</h1>”); } Test class: [TestMethod] Void ShowMessage_returns_correct_message_string() { var presenter = new Presenter(_fakeView); string actual = presenter.ShowMessage(“Hello,”, “Bill”); Assert.AreEqual(“Hello, Bill”, actual); }
  • 23. Unit tests with SharePoint SSOM – possible approaches (2) Proprietary Mocking frameworks (Typemock Isolator, JustMock, Microsoft Fakes f/w)  Fake SharePoint framework (v. diff.) 
  • 24. Code Coverage (and other dubious metrics) Your Custom Code SharePoint .NET SharePoint Unmanaged Code ASP.NE SQL T Windows OS
  • 25. Unit tests with SharePoint SSOM – possible approaches (3)  Accept shallow integration tests in lieu (“unigration tests”)
  • 26. Demo: Server-side testing
  • 27. Client-side testing The new model – SharePoint-hosted Apps  Unit testing JavaScript  Faking the _api  Shallow integration (“unigration”) tests  Surely this is the Java logo?
  • 28. Options for client-side JavaScript testing Ad-hoc tests (e.g. console logging)  QUnit (    Jasmine   TDD style BDD style Mocha BDD or TDD style  PYO assertion library   UI tests (e.g. Selenium, VS UI tests)
  • 29. Running tests Can run tests in a browser window  Chutzpah test runner  Command line and Visual Studio integration  Only supports Jasmine and Qunit   For Continuous Integration use PhantomJS Headless browser  Chrome browser engine (WebKit)    Use a cloud test service for “cross-browser test”  Includes device browsers
  • 30. Demo: Client-side testing
  • 31. Tips for Testing JavaScript Keep JavaScript modular in files, not scattered amongst HTML  To be able to Unit Test you need units  In JavaScript the unit of code encapsulation is the function  Very difficult to test an anonymous function  Very difficult to test a hidden function – may need to compromise encapsulation to make testable  Isolate tests from mark-up to avoid fragility 
  • 32. The ATDD Cycle User Story Write Acceptance Tests Acceptance Tests Pass Demo to PO QA write test refacto r pass
  • 33. How does ATDD work? Similar to BDD  A DSL for business users to define automated acceptance tests  Tooling such as Fitnesse, SpecFlow  Developer creates generic test fixtures  Can write tests first to drive development (outer loop – inner loop is TDD)  Gives test team something to do 
  • 34. How do we do acceptance tests?      End-to-end testing No requirement for tests to be fast (within reason) Tools like SpecFlow can be used to define tests (but is it worth it?) More likely a QA professional will manually build automated QA tests Tools:   Selenium WebDriver Visual Studio UI tests
  • 35. End-to-end Testing        Best suited for acceptance tests Drives application through the UI Selenium WebDriver, Watin, Visual Studio Can target different browsers Fully tests DOM manipulation, JavaScript, interaction with back-end (i.e. SharePoint) These tests often written by a dedicated tester Can be used for TDD but only if they are fast enough
  • 36. Conclusions Test Driven Development continues to gain traction in the development community as a whole and brings many benefits  SharePoint challenges us to find new ways of testing server-side code  The SharePoint 2013 App model brings with it a new world of client-side testing  Good news: client-side code is easier to test than server-side SharePoint code  Some end-to-end testing will be necessary particularly for acceptance tests 
  • 37. Recommended Reading: “The Art of Unit Testing”, Roy Osherove   “Clean Code – A Handbook of Agile Software Craftsmanship”, Robert C Martin  Lean-Agile Acceptance Test-Driven Development, Ken Pugh 
  • 38. Contact me: Blog:  Twitter: @spdoctor  (moderator)  Email: 