Automated Builds And UI Testing in SharePoint 2010 Development

6,503 views
6,262 views

Published on

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.

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,503
On SlideShare
0
From Embeds
0
Number of Embeds
114
Actions
Shares
0
Downloads
111
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Automated Builds And UI Testing in SharePoint 2010 Development

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

×