Lab version: 11.0.60315.01 Update 2 Last updated: 4/9/2013
CONTENTS
OVERVIEW ................................................................................................................................................... 3 EXERCISE 1: CREATING UNIT TESTS USING THE SHAREPOINT EMULATOR ................................... 5 EXERCISE 2: INTELLITRACE SUPPORT FOR SHAREPOINT ............................................................... 17 EXERCISE 3: WEB AND LOAD TESTING SHAREPOINT APPLICATIONS ........................................... 25
Overview In this lab, you will learn about new features provided in Update 1 and 2 that make testing and debugging SharePoint applications easier, thereby helping to improve the quality and scalability of your product. Although this lab walks through testing and debugging a SharePoint 2010 instance, the steps generally apply to SharePoint 2013 also.
Prerequisites In order to complete this lab you will need the Visual Studio 2012 virtual machine provided by Microsoft. For more information on acquiring and using this virtual machine, please see this blog post. Lab Updates This lab highlights features and enhancements introduced with Visual Studio 2012 Update 1, although some lab steps may also highlight features that were in place prior to the update. Update 1 specific features and enhancements are specifically called out as they are introduced. 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. Log in as Adam. All user passwords are P2ssw0rd. Open the AppointmentsWebPart solution file from C:\SharePointDemos\AppointmentsWebPart in Visual Studio 2012.
Figure 1 Loading sample solution
This solution contains a web part that allows a user to book an appointment. Lets 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 http://vsalm/sites/team.
Figure 3 SharePoint demo site
Select the Edit button to edit the page.
Figure 4 Edit button location
Place the cursor on the page between the paragraph of text and the Shared Documents section.
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 & Close button.
Figure 9 Save and close
The web part expects there to be a list named Appointments, so go ahead and click on the Lists link to create one.
Figure 10 Navigate to Lists
Select the Create button.
Figure 11 Create new list button
Select the Appointments type, enter a name of Appointments, and select the Create button.
Figure 12 Creating Appointments list
Select the Browse button and then select the Team link in the navigation bar to return to the default page.
Figure 13 Return to home page
Manually test the appointment web part by entering some test data into the fields and then select the Submit button.
Figure 14 Testing the Appointments web part
Return to the Appointments list and note that the appointment has been added as expected.
Figure 15 New appointment
Now lets 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 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
Right-click somewhere within the test definition and select Run Tests.
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 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.
Right-click somewhere within the test definition and select Run Tests to make sure it works as expected. The result should be that the unit test passes.
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.
Right-click somewhere within the test definition and select Run Tests once again. This time the test will run against a real SharePoint instance.
Figure 26 Unit test passing through the emulator (note the time difference)
Exercise 2: IntelliTrace Support for SharePoint In this exercise, you will learn about Update 1 improvements made to IntelliTrace that improve the debugging experience of SharePoint applications. Log in as Adam. All user passwords are P2ssw0rd. Open the SharePointProject1 solution file from c:\SharePointDemos\SharePointProject1 in Visual Studio 2012.
Figure 27 Loading sample solution
Open WebPart1.cs from Solution Explorer. Note that this simple web part simply identifies the current user name and renders some output HTML.
Figure 28 Sample web part code
Right-click on the SharePointProject1 project and select Deploy to deploy and activate the feature on the local SharePoint server. Lets go ahead and take a look at this web part in action. Open Internet Explorer and navigate to http://vsalm/sites/team. Select the Site Pages link.
Figure 29 Navigating to Site Pages
Select the Site Actions drop-down and then select New Page.
Figure 30 Creating a new test page
Use IntelliTrace Demo for the new page name and then select Create.
Figure 31 Creating a new test page
Select the Insert tab.
Figure 32 Inserting the web part
Select the Web Part button to add in the custom web part.
Figure 33 Inserting the web part
Select the Custom category, the SharePointProject1 web part and then select the Add button to add it to the page.
Figure 34 Inserting the web part
Select the Save and Close button.
Figure 35 Save changes
Here we can see that the web part is deployed and functional.
Figure 36 Custom web part in action
Now lets 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 37 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 executing the StartIntelliTraceDemo.cmd script found in C:\SharePointDemos.
Figure 38 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 2012 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. Select the Correlation ID and then press Ctrl + C to copy it to the clipboard.
Figure 39 Typical SharePoint error showing correlation ID
Execute the StopIntelliTraceDemo.cmd script to stop IntelliTrace.
Figure 40 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 41 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 lets 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 42 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. Select the Start Debugging button.
Figure 43 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 44 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 45 IntelliTrace debugging
Exercise 3: Web and Load Testing SharePoint Applications In this exercise, you will learn about how Update 1 has improved the Visual Studio 2012 web and load testing tools. To learn more about web and load testing in general, please see the Introduction to Web Performance and Load Testing with Visual Studio Ultimate 2012. Log in as Adam. All user passwords are P2ssw0rd. Open the SP_Web_LoadTest_Demo solution file from c:\SharePointDemos\WebAndLoadTestProject1 in Visual Studio 2012.
Figure 46 Loading sample solution
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 47 Sample web and load test project
Prior to 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. Update 1 performs more of these tedious tasks automatically, and this is configurable. View the available options by selecting Tools | Options | Web Performance Test Tools | Web Test | SharePoint in the main menu of Visual Studio.
Figure 48 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 49 Upload web test definition
Note that the site name was automatically parameterized for us in all of the recorded requests. This makes it easy to data drive the site name if desired.
Figure 50 Site name was automatically parameterized
Expand the second request in the list and note that a SharePoint specific extraction rule was automatically added in to grab the list ID and store it as a context parameter.
Figure 51 SharePoint extraction rule to find list ID
Figure 52 Properties of extraction rule
The list ID context parameter is then used in subsequent requests, for example in the request to Upload.aspx.
Figure 53 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 Doc2.doc file.
Figure 54 File Upload Parameter
In addition to a couple of new validation rules, Update 1 also provides 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 55 Location of Add Extraction Rule option
The additional SharePoint extraction rules allow you to do things like find specific list and document IDs, calendar dates, values of text boxes, workflow instance IDs, and so on.
Figure 56 New SharePoint extraction rules
Press the Escape key to close the Add Extraction Rule window. 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. After the test was recorded, a SharePoint extraction rule was added to find the document item and store it as a context parameter.
Figure 57 Use of a SharePoint extraction rule to find a document item
In the web request to Download.aspx, note that one of the query string parameters refers to the document previously extracted.
Figure 58 Use of document reference previously extracted
Double-click on SPLoadTest1.loadtest from Solution Explorer to load it in the load test editor.
Figure 59 Load test definition
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. Note that Update 1 provides a new counter set definition, SharePoint 2012 WFE.
Figure 60 SharePoint Counter Set
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 61 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 62 Summary results of load test
Figure 63 Graph view of load test results
To give feedback please write to VSKitFdbk@Microsoft.com Copyright 2014 by Microsoft Corporation. All rights reserved.