Automated Builds And UI Testing in SharePoint 2010 Development
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Automated Builds And UI Testing in SharePoint 2010 Development

on

  • 6,702 views

Shows how to introduce automated builds and UI testing to SharePoint 2010 development projects. Team Foundation Server 2010 is used as the build platform. Includes coverage of VS2010 features such as ...

Shows how to introduce automated builds and UI testing to SharePoint 2010 development projects. Team Foundation Server 2010 is used as the build platform. Includes coverage of VS2010 features such as code profiling, IntelliTrace etc.

Statistics

Views

Total Views
6,702
Views on SlideShare
6,603
Embed Views
99

Actions

Likes
3
Downloads
105
Comments
0

6 Embeds 99

http://sharepointkunskap.wordpress.com 62
http://www.linkedin.com 17
http://chuvash.eu 13
https://www.linkedin.com 5
http://translate.googleusercontent.com 1
http://webcache.googleusercontent.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

Automated Builds And UI Testing in SharePoint 2010 Development Presentation Transcript

  • 1. Automated builds and UI testing in Sp2010 development
    Chris O’Brien
    DEV203
  • 2. About me
    Independent SharePoint consultant
    Blog: www.sharepointnutsandbolts.com
    Twitter: @ChrisO_Brien
    Book: Real World SharePoint 2010 (20 MVPs)
    LinkedIn: http://uk.linkedin.com/in/chrisobrienmvp
  • 3. Problems in SP2010 dev projects
    Many dependencies
    Code, Features, timer jobs
    Deployment is complex
    e.g. No native support for WSP rollback
    Difficult to unit test
    Still not much traction in SharePoint world?
  • 4. Problems in *large* SP2010 dev projects
    Tracking
    Hard to keep track of deployments/fixes
    Many developers = many deployments?
    Inefficiency
    Devs keeping environment up-to-date
    Inconsistent builds (or buildmaster bottleneck)
    Silly mistakes e.g.
    Incorrect versions
    Debug vs. Release mode
    Testing of actual WSPs
    Communication
  • 5. Solution recipe
    Auto-compile of assemblies and build of WSPs
    Correct versions in source control
    Add a label in source control to help rollback
    Auto incrementing assembly version number
    Better tracking of deployments/fixes etc.
    Deployment of WSPs to remote SharePoint 2010 environment
    Test environment, not developer machine
    UI testing
    Build fails on UI test failure
    Developer notifications
  • 6. Solution ingredients
    TFS Team Build workflow (.Net4.0)
    Specifies sequence of steps
    PowerShell
    Deploys WSPs, other deployment steps e.g. teardown/setup site
    PowerShell remoting(preferred over PsExec)
    Allows PS on SharePoint box to be called from build server
    Invoke-Command -ComputerName “foo” { script }
  • 7. Automating the build
  • 8. Build definition
    Styles:
    What’s the trigger?
    Manual, Scheduled (e.g. nightly), every check-in, Rolling builds, Gated Check-In etc.
    Customise workflow
    Mandatory for SharePoint builds
    Several workflows OOTB
    DefaultTemplate, LabTemplate
  • 9. demo
    Automating the build
  • 10. Image: selecting build trigger
  • 11. Image: customizing build workflow
  • 12. COdedui tests
  • 13. What is a coded UI test?
    Recorded on test agent desktop
    Support: browser (inc. AJAX), Silverlight, WPF, forms apps
    Generate code which can be modified (e.g. to pass data)
    Point and click to add assertions
    E.g. navigate to web part gallery, check web part present
  • 14. demo
    Testing SharePoint with coded UI tests
  • 15. Image: recording a UI test
  • 16. Adding COdedui tests to the build
  • 17. Integrating coded UI tests into build
    Automatic if test assembly name matches filespec
    Default = “*test*” somewhere in assembly name
    Background:
    All tests can be run from command-line with MSTest.exe (Unit tests, Coded UI tests, Load tests, Etc.)
    Team Build ships with MSTest WF activity (wrapper)
    The OOTB workflows contain this activity
    Caveat:
    OOTB workflows must be edited to deploy WSPs and/or run coded UI tests
  • 18. demo
    Catching code issues with build/test process
  • 19. Image: build summary
  • 20. Image: test results for build
  • 21. Image: analyzing failed test (1)
  • 22. Image: analyzing failed test (2)
  • 23. Why stop at UI testing?
  • 24. Image: code profiling in build (1)
  • 25. Image: code profiling in build (2)
  • 26. Image: IntelliTrace in build
  • 27. Best practices
    Start on day 0 of project
    Retro-fitting can be expensive
    Get fast feedback - have a lightweight/quick build run on check-in
    Compile all projects/build WSPs
    Suggestion - every SharePoint project should do this much
    Increment assembly versions (FileVersion) with label generated by build
    Leverage UI testing (with or without automated builds)
  • 28. Resources
    Setting up TFS to build SharePoint Projects - http://bit.ly/9lEqnP
    Assembly versions in build workflow - http://bit.ly/eRPB0e
    Running tests as part of a build - http://bit.ly/i41eze
    PS remoting and SharePoint 2010 - http://bit.ly/9Cb4tF
    Also on my blog soon:
    My customized workflow and PS scripts
    Multi-part article series on automated builds/testing
    www.sharepointnutsandbolts.com
  • 29. Thank you!
  • 30. Appendix slides
  • 31. What you need - software
    Automated builds = TFS 2010 (Team Build)
    Server + 1 CAL free with every MSDN level
    Need CAL for every user who interacts
    Components: Build Controller, Build Agent
    Coded UI tests = Visual Studio 2010 Premium/Ultimate (OR ‘Test Elements’ add-on)
    Components: Test Controller, Test Agent
  • 32. What you need - hardware
    Option 1 – the EASY button
    Disadvantages:
    Risk to source control
    Performance
    SP2010 + TFS2010 = big resource reqs
    Bottom line:
    Don’t do this with prod source control!
  • 33. What you need - hardware
    Option 2 – a sample topology
  • 34. PowerShell remoting
    To enable:
    To run:
    Invoke-Command -ComputerName“foo” { script }