Testing and Debugging SharePoint Applications with

Hands-On Lab
Testing and Debugging SharePoint
Applications with Visual Studio 2013
Lab version:
12.0.30723.00 Update 3
Last updated:
9/10/2014
CONTENTS
OVERVIEW ................................................................................................................................................... 3
EXERCISE 1: CREATING UNIT TESTS USING THE SHAREPOINT EMULATOR ................................... 5
EXERCISE 2: INTELLITRACE SUPPORT FOR SHAREPOINT ............................................................... 19
EXERCISE 3: WEB AND LOAD TESTING SHAREPOINT APPLICATIONS ........................................... 27
Overview
In this lab, you will learn about some of the features provided with Visual Studio 2013 that make testing
and debugging SharePoint applications easier, thereby helping to improve the quality and scalability of
your product.
Prerequisites
In order to complete this lab you will need the Visual Studio 2013 virtual machine provided by Microsoft.
For more information on acquiring and using this virtual machine, please see this blog post.
Change log
For Update 3:

Screenshot updates as necessary, other minor edits
Exercises
This hands-on lab includes the following exercises:
Creating Unit Tests using the SharePoint Emulator
IntelliTrace Support for SharePoint
Web and Load Testing SharePoint Applications
Estimated time to complete this lab: 60 minutes.
Exercise 1: Creating Unit Tests using the
SharePoint Emulator
In this exercise, you will learn how to take advantage of the SharePoint Emulator in your unit tests in
order to help remove unnecessary dependencies to SharePoint and the SharePoint API, thereby isolating
your tests and making sure that you are testing the code you want.
Note: Please note that in the virtual machine you may notice delays when attempting to open the
team project portal while the necessary SharePoint services are started for the first time, and you may
notice timeouts or unexpected errors.
In most cases, you can keep refreshing the page until it loads. Note that it may take a few minutes
depending on the performance of the hardware you are hosting this virtual machine on. If after a few
minutes it still doesn’t load, please confirm that you have configured this virtual machine according to
the proper setup instructions. This includes ensuring that you have at least one network adapter
installed and configured (an internal network adapter is recommended).
Log in as Adam (VSALM\Adam). All user passwords are P2ssw0rd.
Launch Visual Studio 2013 from the taskbar and then open the AppointmentsWebPart solution
from C:\SharePointDemos\AppointmentsWebPart (File | Open | Project/Solution…).
Figure 1
Loading sample solution
Note: The taskbar link for Visual Studio has been configured to ‘run as administrator’, which is
necessary for some operations such as deploying to SharePoint.
This solution contains a web part that allows a user to book an appointment. Let’s take a look at
it in action to get an idea of what it does. Right-click on the AppointmentsWebPart project in
Solution Explorer and select Deploy to deploy and activate the feature on the local SharePoint
server.
Figure 2
Deploying the web part
Open Internet Explorer and navigate to the SharePoint site at http://vsalm.
Figure 3
SharePoint site
Select the Edit button to edit the page.
Figure 4
Edit button location
Place the cursor at the beginning of the page that is now in edit mode. It may be helpful to use
the arrow keys in addition to the mouse.
Figure 5
Selecting insert location
Select the Insert tab.
Figure 6
Insert tab location
Select the Web Part button to add in the custom web part.
Figure 7
Web Part button
Select the Custom category, the AppointmentsWebPart and then select the Add button to add
it to the page.
Figure 8
Adding in the web part
Select the Save button.
Figure 9
Save and close
The web part expects there to be a list named Appointments. To create one, select the gear
icon from the top-right and then select the ‘Add an app’ option.
Figure 10
Navigate to Lists
Select the Appointments app tile.
Figure 11
Create Appointments app
Enter a name of Appointments and select the Create button.
Figure 12
Creating Appointments app
Return to the home view for the site. One way to do this is to select the Home link from the lefthand navigation menu.
Figure 13
Returning to home view
Manually test the appointment web part by entering some test data into the fields and then
selecting the Submit button.
Figure 14
Testing the Appointments web part
Return to the Appointments app (look underneath the Recent node) and note that the
appointment has been added as expected.
Figure 15
New appointment
Now let’s take a look at how we can take advantage of the SharePoint Emulator and Microsoft
Fakes Framework to develop and execute unit tests. The SharePoint Emulator code base is
installed via NuGet. Return to Visual Studio, right-click on the AppointmentsWebPart.Tests
project and select the Manage NuGet Packages option.
Figure 16
Manage NuGet packages
You should see that the Microsoft.SharePoint.Emulators package is already installed for the
test project. The package downloads needed assemblies and adds the appropriate references to
the project for you.
Figure 17
Microsoft.SharePoint.Emulators already added to project
Close the Manage NuGet Packages window.
Load the UnitTest1.cs file from the AppointmentsWebPart.Tests project and navigate to the
first test method that starts with “ScheduleAppointment…” This test method uses the
SharePoint Emulator to create a test list, add fields to it, and then use the web part to test the
scheduling of an appointment.
Figure 18
Unit test definition
Most of what you see looks identical to normal SharePoint code, however it is all wrapped in a
Using statement with an instance of SharePointEmulationScope. This is responsible for
redirecting normal SharePoint calls to the shims provided by the emulator.
Figure 19
Use of SharePointEmulationScope
Select the Test Status indicator just above the test method definition and then select the Run
link. If it isn’t visible yet, try pressing Ctrl + Shift + B to build the solution first.
Figure 20
Run unit test
Note that this test reports success.
Figure 21
Successful unit test run with SharePoint Emulator
Note: If the unit test unexpectedly fails, please restart Visual Studio and try again.
Scroll down to the second test method and take a look at what it does. It creates a list, inserts
test appointments into the list, and then calls the GetAppointmentsForToday method from the
web part under test to ensure that appointments for the current date are returned. It also uses
the same SharePointEmulationScope as before.
Figure 22
Unit test definition
As you work with the SharePoint Emulator, you may run into circumstances where features
have not yet been implemented. In these cases, expect to see a NotSupportedException occur
during test runs with information about the unimplemented shim. It turns out that the
GetAppointmentsForToday method on the web part under test makes use of the
SPList.GetItems method, which will throw a NotSupportedException when running the version
of the SharePoint Emulator installed on this VM.
Fortunately, it is straightforward to specify an implementation of the missing shim, as
evidenced by the following code from the test method. Note that there is an explicit test to run
this code block when running in emulation mode.
Figure 23
Implementing a shim
Note: This shim implementation simply grabs the first item from the list for the purposes of
this demo, regardless of the query passed in. If you would like to learn more about the
Microsoft Fakes Framework, please see the MSDN documentation here.
Select the Test Status indicator just above the test method definition and then select the Run
link to make sure it works as expected.
Figure 24
Unit test results
You can also run your unit tests against a real SharePoint instance by changing the emulation
mode to bypass all shims and directly call into the original SharePoint assembly. Scroll to the top
of the “GetAppointments…” test method and change EmulationMode.Enabled to
EmulationMode.Passthrough.
Figure 25
Configuring unit test to pass through the emulator
Note: In a real-world scenario, you would likely want to re-use your unit test code in both
emulated and passthrough modes. To do this, you could define the emulation mode to use at
the test class level and use test initialize and cleanup to create and destroy the scope.
Automation of the selected emulation mode could then be implemented using preprocessor
directives, with the definition provided in the test project file or via the build command line.
For more information, please see the MSDN SharePoint Emulator article here.
Before we run the modified test, we need to change the Default Processor Architecture to X64
in Test | Test Settings. Otherwise, you will receive an error asking you to do just this in the next
step.
Run the test once again, but note that this time the test will run against a real SharePoint
instance. Note that it takes significantly longer to execute this test.
Figure 26
Unit test passing through the emulator
Exercise 2: IntelliTrace Support for
SharePoint
In this exercise, you will learn about how to utilize IntelliTrace to improve the debugging experience of
SharePoint applications.
Log in as Adam (VSALM\Adam). All user passwords are P2ssw0rd.
Launch Visual Studio 2013 from the taskbar and then open the SharePointProject1 solution file
from c:\SharePointDemos\SharePointProject1.
Open WebPart1.cs from Solution Explorer. Note that this simple web part simply identifies the
current user name and renders some output HTML.
Figure 27
Sample web part code
Right-click on the SharePointProject1 project and select Deploy to deploy and activate the
feature on the local SharePoint server.
Let’s go ahead and take a look at this web part in action. Open Internet Explorer and navigate to
http://vsalm.
Select the gear icon from the top-right and then select the ‘Add a page’ option.
Figure 28
Creating a new page
Use “IntelliTrace Demo” for the new page name and then select Create.
Figure 29
Creating a new test page
Select the Insert tab.
Figure 30
Insert tab location
Select the Web Part button to add in the custom web part.
Figure 31
Web Part button
Select the Custom category, the SharePointProject1 web part and then select the Add button
to add it to the page.
Figure 32
Inserting the web part
Here we can see that the web part is deployed and functional.
Figure 33
Custom web part in action
Select the Save button.
Figure 34
Saving the page
Now let’s assume that this web part has been working for some time but that an additional
feature has been added in and users are now reporting intermittent errors. Return to Visual
Studio and uncomment the line that throws an exception.
Figure 35
Artificially introducing an exception for demo
Right-click on the SharePointProject1 project and select Deploy to deploy the updated web
part.
At this point, you can use IntelliTrace to collect diagnostic data for SharePoint using the
IntelliTrace PowerShell module. Start IntelliTrace by right-clicking on StartIntelliTraceDemo.cmd
and selecting the “Run as administrator” option. This script can be found in
C:\SharePointDemos.
Figure 36
Start IntelliTrace session
Note: If you would like to learn more about how to use IntelliTrace in a production
environment, including the details involved with these scripts, please see the “Diagnosing
Issues in Production with IntelliTrace and Visual Studio 2013” lab.
After IntelliTrace has started, return to Internet Explorer and refresh the “IntelliTrace Demo”
page. An error page should now be displayed by SharePoint. This is something that an end user
would likely see and then report back to the development team. Expand the “Technical Details”
section, highlight the Correlation ID and then press Ctrl + C to copy it to the clipboard.
Figure 37
Typical SharePoint error showing correlation ID
Execute the StopIntelliTraceDemo.cmd script to stop IntelliTrace (run as administrator).
Figure 38
Stop IntelliTrace session
The scripts that executed IntelliTrace collection were configured to output data to
C:\LogFileLocation. Double-click on the IntelliTrace file found at that location to load it in Visual
Studio.
Figure 39
IntelliTrace log file
In the IntelliTrace Summary view, note that there is an Analysis section at the top that shows
an unhandled exception. We could start debugging the unhandled exception by clicking on the
Debug Exception button, but let’s start by pasting the Correlation ID we received from our end
user in to the blank text box (use Ctrl+V) to review matching web requests. Select the View
Details button.
Figure 40
Viewing web request details associated with Correlation ID
Here we can see request information associated with the SharePoint Correlation ID. We can see
the target URL, user agent, and so on.
Figure 41
Web request details
Close the web request details window and return to the IntelliTrace file.
Select the Debug Exception button to the right of the unhandled exception.
Figure 42
Start debugging the unhandled exception
Once Visual Studio is in debug mode, you should see that the location of the unhandled
exception is highlighted in the WebPart1.cs source file and that you have the normal IntelliTrace
debugging tools at your disposal.
Figure 43
IntelliTrace debugging
You can now stop the debugging session and close this instance of Visual Studio.
Exercise 3: Web and Load Testing
SharePoint Applications
In this exercise, you will learn about how web and load testing tools work with SharePoint applications.
To learn more about web and load testing in general, please see the “Introduction to Web Performance
and Load Testing with Visual Studio Ultimate 2013”.
Log in as Adam (VSALM\Adam). All user passwords are P2ssw0rd.
Launch Visual Studio 2013 from the taskbar and then open the SP_Web_LoadTest_Demo
solution file from c:\SharePointDemos\WebAndLoadTestProject1.
This solution contains a test project with two web tests and a load test. We will take a closer
look at these in a moment.
Figure 44
Sample web and load test project
Prior to Visual Studio 2012 Update 1, it was certainly possible to record web tests against
SharePoint, but it required you to significantly hand edit the recording to do things such as
remove extraneous requests and parameterize the site name. Visual Studio now handles many
of these tedious tasks automatically. View the available options by selecting Tools | Options |
Web Performance Test Tools | Web Test | SharePoint in the main menu of Visual Studio.
Figure 45
SharePoint web test options (showing defaults)
After taking a look at the default options for SharePoint web tests, press Escape to exit the
Options window.
Open Upload.webtest in the web test editor. This web test was recorded by navigating to a
SharePoint site, loading the Shared Documents library, and uploading a document.
Figure 46
Upload web test definition
Expand the first request to AllItems.aspx in the list and note that a SharePoint specific
extraction rule was automatically added to grab the list ID and store it as a context parameter.
Figure 47
SharePoint extraction rule to find list ID
Figure 48
Properties of extraction rule (press F4)
The list ID context parameter is then used in subsequent requests, for example in the request to
Upload.aspx.
Figure 49
Use of list ID context parameter
The actual file that is uploaded during the test run is parameterized as well. Expand the second
web request to Upload.aspx (there are two) and scroll to the bottom of the Form Post
Parameters and select last option, which is a File Upload Parameter. This shows that when we
run the web test, a unique filename will be used when uploading the file.
Figure 50
File Upload Parameter
Double-click on Download.webtest in Solution Explorer to load it in the web test editor. This
web test was recorded by navigating to a SharePoint site, loading the Shared Documents library,
and downloading a specific document.
Expand the second request to Home.aspx and note that there are already a few SharePoint
related extraction rules in place. These extract values such as List and View ID values and store
them in context parameters for use in later requests.
Figure 51
SharePoint extraction rules
After the test was recorded, a SharePoint extraction rule was automatically added to find the
document item ID and store it as a context parameter using the “SharePoint – Extract Text on
Key” rule.
Figure 52
Use of a SharePoint extraction rule to find a document item
There are a number of useful extraction rules that you can use with your SharePoint web
requests. Right-click on one of the web requests and select the Add Extraction Rule option.
Figure 53
Location of Add Extraction Rule option
The additional SharePoint extraction rules allow you to do things like find a specific list and
document IDs, calendar dates, values of text boxes, workflow instance IDs, and so on. Scroll to
the right in order to see more rules.
Figure 54
New SharePoint extraction rules
Press the Escape key to close the Add Extraction Rule window.
Double-click on SPLoadTest1.loadtest from Solution Explorer to load it in the load test editor.
This is a basic load test definition that will spend half of the time on the Download web test and
the other half on the Upload web test.
Figure 55
Load test definition
Go ahead and run the load test to see it in action by selecting the Run Load Test button. The
load test is configured to run for 1 minute.
Figure 56
Location of Run Load Test button
After the results summary displays, you can see the individual page result details if you scroll
down. To visualize the performance details over time, you can also try the Graphs view.
Figure 57
Summary results of load test
Figure 58
Graph view of load test results
To give feedback please write to VSKitFdbk@Microsoft.com
Copyright © 2016 by Microsoft Corporation. All rights reserved.