Hands-On LabLab Management Improvements in Visual Studio 2012Lab version: 11.0.60315.01 Update 2

Last updated: 4/9/2013

CONTENTS

OVERVIEW................................................................................................................................................. 3

EXERCISE 1: PREPARING A TEST AGENT MACHINE...........................................................................4

EXERCISE 2: CONFIGURING THE TEST CONTROLLER........................................................................5

EXERCISE 3: CREATING A STANDARD ENVIRONMENT.......................................................................7

EXERCISE 4: PREPARING FOR AUTOMATED TESTING.....................................................................18

EXERCISE 5: CREATING AND RUNNING A BUILD-DEPLOY-TEST DEFINITION...............................26

Overview

In this lab, you will learn about some of the new features and improvements in lab management for Visual Studio 2012. This includes the creation of standard environments, which allows existing test environments to be added into Lab Management, with no infrastructure prerequisites and no configuration needed in Team Foundation Server. In addition, there is no longer a need to spend much time with the test agents, as there is only one test agent type and the agents are automatically installed on the test environments. After completing this lab, you will have a good idea how easily and quickly you can now get a build, deploy, and test workflow setup using your existing development environment.

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.

About the Fabrikam Fiber Scenario

This set of hands-on-labs uses a fictional company, Fabrikam Fiber, as a backdrop to the scenarios you are learning about. Fabrikam Fiber provides cable television and related services to the United States. They are growing rapidly and have embraced Windows Azure to scale their customer-facing web site directly to end-users to allow them to self-service tickets and track technicians. They also use an on-premises ASP.NET MVC application for their customer service representatives to administer customer orders.

In this set of hands-on labs, you will take part in a number of scenarios that involve the development and testing team at Fabrikam Fiber. The team, which consists of 8-10 people, has decided to use Visual Studio application lifecycle management tools to manage their source code, run their builds, test their web sites, and plan and track the project.

Exercises

This hands-on lab includes the following exercises:

1. Preparing a Test Agent Machine

2. Configuring the Test Controller

3. Creating a Standard Environment

4. Preparing for Automated Testing

5. Creating and Running a Build-Deploy-Test Definition

Estimated time to complete this lab: 60 minutes.

Exercise 1: Preparing a Test Agent Machine

In this preparatory exercise, we will create and configure the second virtual machine that will be used later on in this lab. To minimize the size of the download, we will create and use another instance of the Visual Studio 2012 virtual machine as a test agent machine.

Note: The instructions provided in this section apply to Hyper-V running in Windows Server 2008 R2 SP1, but the overall steps generally apply to Windows 8 Hyper-V as well.

1. At this point, you should already have an instance of the Visual Studio 2012 virtual machine setup after following the Prerequisites section of this document. Perform this setup step if not already completed.

2. In Hyper-V Manager, create a snapshot of the working virtual machine and name it something like “Visual Studio 2012 Base”.

3. Right-click on the base snapshot and select the Export option.

4. In the Export Virtual Machine dialog, choose a location that has space and that is on a different physical disk (if possible).

5. Click the Export button to start the export process. This will take a few minutes to complete.

6. After the export is complete, click the Import Virtual Machine button within Hyper-V Manager.

7. Select the location of the recent export and make sure to select the “Copy the virtual machine (create a new unique ID)” option under import settings.

8. Boot the first instance of the virtual machine (machine name is VSALM).

9. Boot the second instance of the virtual machine and execute the ConfigureVSALM2.bat file found in c:\util to change the machine name to VSALM2 and perform other necessary configuration. You can log in as Administrator – all user passwords are P2ssw0rd.

10. Reboot the newly minted VSALM2 machine so that the new name takes effect.

11. Ensure that the two virtual machines can communicate with each other. One way to do this is to ensure that they are both configured to use an Internal Only virtual network adapter and are configured to both be on the same VLAN.

12. Log into VSALM2 and ensure that you can ping the VSALM machine by loading a command prompt window and entering “ping -4 VSALM”. If this is a success, you are ready to continue with the lab.

13. Take a snapshot of the VSALM2 virtual machine so that you can reset the lab later if desired.

Exercise 2: Configuring the Test Controller

In this exercise, you will learn how to configure the Test Controller. The Test Controller software has already been installed and configured on the virtual machine, so we will just take a quick look at it.

1. Log in as Adam on the VSALM machine. All user passwords are P2ssw0rd.

2. Launch the Test Controller Configuration Tool from Start | All Programs | Microsoft Visual Studio 2012.

Figure 1Launching the Test Controller Configuration Tool

3. In the Configure Test Controller window, note that test controller is already registered with a team project and that a lab service account is specified. Registering with a team project collection will enable us to create a virtual environment to run automated tests against later on in the lab. If you just wanted to run tests from Visual Studio, you would instead keep the test controller unregistered.

Figure 2Test Controller Configuration

4. Click the Close button and exit without applying the settings.

Figure 3Exiting test controller configuration without changes

Note: If you would like to make changes to the test controller configuration for purposes outside of this lab, execute the ConfigureTestController.bat script found in the c:\util folder in the virtual machine. We have some non-standard modifications in place so that demo URLs will resolve correctly (such as http://www.fabrikam.com), and this script temporarily disables these modifications so that the test controller can properly finish configuration.

Exercise 3: Creating a Standard Environment

In this exercise, you will learn how easy it is to create a standard environment to use with your automated testing scenarios. Note that it really does not matter if this is a real machine or a virtual machine, running on Hyper-V or VMware, as long as you can connect to it you can use it for your testing.

1. Log in as Adam on the VSALM machine. This is where we will initiate the creation of the standard environment using Microsoft Test Manager. The environment itself, once installed and configured, will run on the VSALM2 machine.

2. Launch Microsoft Test Manager from Start | All Programs | Microsoft Visual Studio 2012.

Figure 4Launching Microsoft Test Manager

3. Microsoft Test Manager will connect to the team project that was last in use on startup. Select the Home button in the upper-left corner to select a different project.

Figure 5Location of home button

4. Click on the Change Project link.

Figure 6Changing the active project

5. When you are prompted to connect to a team project, select the VSALM -> FabrikamFiberCollection -> FabrikamFiber node and then select the Connect Now button. When you are prompted to close all open items, go ahead and do so.

Figure 7Connecting to a team project

6. Select the Default test plan and then select the Select Plan button to continue.

Figure 8Selecting a test plan

7. In Microsoft Test Manager, select the drop-down arrow just to the right of the Testing Center and select Lab Center.

Figure 9Navigating to the Lab Center in Microsoft Test Manager

8. Select the New button in the Environments section.

Figure 10Creating a new standard environment

9. In our case, we will create a new standard environment, which means that we will use an existing machine that is already setup and ready for testing. For the name of the new environment, enter “Fabrikam BDT” which stands for Build-Deploy-Test and then select the Next button to continue.

Figure 11Creating a new standard environment

Note: In Visual Studio 2012, there is more support for virtual machine template features, which will be managed in SCVMM 2012, rather than in Lab Manager. There is also better

separation of concerns between Team Foundation Server admins and SCVMM admins, as the TFS service account no longer has to be an administrator on all hosts.

10. Select the Add Machine button.

Figure 12Adding a machine to the new standard environment

11. We will use the duplicated virtual machine here, so type “VSALM2” for the computer name and select the “Web Server” role.

12. Enter “.\Adam” for the user name and “P2ssw0rd” for the password.

Figure 13Adding a machine to the new standard environment

Note: You could add more machines to the environment if needed to fill different roles for testing, such as database server, domain controller, etc.

13. Select the Advanced step on the left-hand side.

Figure 14Moving on to the Advanced environment setup step

14. Here we can select the test controller to associate with this new environment and optionally configure it to run UI tests. Select the “Configure environment to run UI tests” checkbox, select the Web Server role, and go ahead and specify that the Adam account will be used for running the test agent.

Figure 15Configuring the test agent to run UI tests

15. Select the Verify button to verify the selections that you made for the new standard environment. As you wait, note that the wizard ensures that the test controller is available, that

the machines and credentials you provided will work, and that the machine is not already part of another environment.

Figure 16Verifying the new environment selections made

16. After the verification step passes, select the Finish button to start the process of installing the test agent in the environment. Note that the test agent installation and configuration proceeds automatically.

Note: The Test Agent installation and configuration is taken care of for you, whereas with previous versions you had to do this yourself. It will take a few minutes for the test agent to install and for the new standard environment to be ready for use. As the test agent is installed, the VM will automatically restart if necessary.

Figure 17Starting the process of standard environment creation

17. As you wait for the test agent to be installed and configured, note that the status of the installation goes through a number of states to keep you informed of progress. This step will take some time to complete.

Figure 18Status of standard environment creation

18. As part of the standard environment setup and installation of the test agent on VSALM2, that virtual machine will restart and automatically log in with the Adam user account. It will take a few minutes for this process to complete, but once it is done, you should see the Test Agent Status window appear on the test agent machine and report an Online status.

Figure 19Test Agent Status screen running on test agent machine (VSALM2)

19. Also, note that the environment is reported as being in the Ready state within Microsoft Test Manager (on VSALM). It can take a few minutes for the test controller machine to report the Ready state even after the test agent machine reports that it is online. We are now ready to create an automated Build-Deploy-Test workflow.

Figure 20Microsoft Test Manager showing the environment as ‘Ready’

Exercise 4: Preparing for Automated Testing

In this exercise, you will use an existing coded UI test to automate an existing test case and create test settings to indicate that we would like to use the new standard environment to perform automated tests.

1. Log in as Adam on the VSALM machine.

2. Let’s say that we already have a test case in place that has been used by the Fabrikam Fiber team for manual testing, and that it has an action recording associated with it. In addition, the team has created a coded UI test based on that action recording that allows them to kick off an automated test at any time in their development environment. Let’s take this existing groundwork and use it to automate tests in an external test environment.

3. Launch Visual Studio 2012 from the shortcut on the taskbar or from Start | All Programs | Microsoft Visual Studio 2012.

Figure 21Starting Visual Studio 2012

4. Open the FabrikamFiber.CallCenter solution from the Dev branch in Source Control Explorer.

Figure 22Source Control Explorer window

5. Select Build | Build Solution from the main menu to build the solution. This will ensure that the coded UI test is available when picking automation for the existing test case.

6. In Team Explorer – Home, select the New Query link.

Figure 23Creating a temporary query

7. In the new query window, change the clause for the Work Item Type field to have value “Test Case”, and then select the Run button.

Figure 24Locating the existing test case

8. Double-click on the test case with title “Create new customer record” to open it.

Figure 25Opening existing test case

9. Select the Associated Automation tab link.

Figure 26Location of Associated Automation link

10. Select the ellipses (…) button to choose a test to use for automation.

Figure 27Location of ellipses button

11. In the Choose Test window, select the CodedUITestMethod1 test and then select the OK button.

Figure 28Selecting test to use for automation

12. Select the Save Work Item button to save the test case.

Figure 29Saving the new test case

Note: You can also use a command line tool (tcm.exe) to create test cases from an assembly of automated tests.

13. Now that we have the test case automation taken care of, let’s create the test settings that we will use later on in the lab. In Microsoft Test Manager, navigate to the Lab Center – Test Settings view and select the New button.

Figure 30Creating automated test settings

14. For the Name, enter “Fabrikam BDT Test Settings”. Next, select the Automated option.

Figure 31Creating automated test settings

15. Select the Roles step on the left-hand side and then select the only role that is listed. This role matches the Fabrikam BDT environment that you created in the previous exercise.

Figure 32Creating automated test settings

16. Select the Data and Diagnostics step to view the data collection options that you can optionally enable for the Web Server role.

Figure 33Data and Diagnostics step for test settings

17. For the purposes of this lab, leave the default selections in place and then select the Advanced step. Note that we can specify additional deployment items, scripts to run before or after test runs, and more.

Figure 34Advanced step for test settings

18. Select the Finish button to save the new automated test settings.

Figure 35Creating automated test settings

Exercise 5: Creating and Running a Build-Deploy-Test Definition

In this exercise, you will learn how to create a build definition that will build, deploy, and test the Fabrikam Fiber solution using the test plan and standard environment that you just created.

1. Log in as Adam on the VSALM machine.

2. The first step is simply to create the build definition that we will use as part of a build-deploy-test workflow.

3. In Visual Studio, navigate to Team Explorer – Builds and select the New Build Definition link.

Figure 36Creating a new build definition

Note: We may technically be able to utilize the existing “Nightly Fabrikam (Dev)” build as part of our new build-deploy-test workflow, but the name of the build indicates that it is triggered to run on a schedule, so we will go ahead and create a new definition.

4. Enter “FabrikamFiber Dev branch build” for the build definition name and then navigate to the Build Defaults tab.

Figure 37

Creating a new build definition

5. In the Build Defaults tab, configure the build output to drop to \\vsalm\ffdrops folder and then navigate to the Process tab.

Figure 38Creating a new build definition

Note: The drops folder was configured ahead of time in the VM. If you needed to create your own drop folder on a network share, you would need to ensure that the account used by the build controller has proper access.

6. In the Process tab, expand the Advanced section and change the Disable Tests property to True. We just want this build definition to be responsible for creating the build that we use for our automated testing.

Figure 39Disable the execution of tests for the build

7. Press Ctrl + S to save the new build definition.

8. Now we can create the build definition that will execute our desired build-deploy-test workflow using all of the pieces that we have setup for automated testing.

9. Select the New Build Definition link in the Team Explorer – Builds window.

10. Enter “Build Deploy Test” for the build definition name and then navigate to the Build Defaults tab.

Figure 40Creating a new build definition for build-deploy-test workflow

11. In the Build Defaults tab, configure the build so that it does not copy output files to a drop folder and then navigate to the Process tab.

Figure 41Creating a new build definition for build-deploy-test workflow

12. In the Process tab, select the Show Details button.

Figure 42Creating a new build definition for build-deploy-test workflow

13. Select LabDefaultTemplate.11.xaml as the build process template.

Figure 43Creating a new build definition for build-deploy-test workflow

14. Select the Lab Process Settings row in the build process parameters section, and then select the ellipses button to start the Lab Workflow Parameters wizard.

Figure 44Creating a new build definition for build-deploy-test workflow

15. Select the Environment step on the left-hand side and then select the “Fabrikam BDT” environment that you just created.

Figure 45

Defining lab process settings for build-deploy-test workflow

16. Select the Build step on the left-hand side and then select the “FabrikamFiber Dev branch build”. Leave the default to queue a new build selected.

Figure 46Defining lab process settings for build-deploy-test workflow

17. Select the Deploy step on the left-hand side and then select the option to “Deploy the build”.

Figure 47Defining lab process settings for build-deploy-test workflow

18. We now need to specify what script to run in the test environment in order to deploy our build for testing. Select the Add button to add a deployment machine to the list, and then type the following into the “Deployment script and arguments” column.

"$(BuildLocation)\Deploy\deploy.bat" "$(BuildLocation)"

Note: This deployment script simply executes a script that does the actual dirty work in deploying the FabrikamFiber web application after it is built. The deploy.bat file is part of the FabrikamFiber.Web project and is configured to output to the build location. The location of

the build (located at the \\vsalm\ffdrops share) is also passed as a parameter to the deploy script so that it knows where to get the latest bits from.

19. Press the Tab key to accept the changes to the field.

Figure 48Defining lab process settings for build-deploy-test workflow

20. Select the Test step on the left-hand side and then select the option to “Run these tests in the environment”. Ensure that the “Fabrikam BDT Test Settings” are selected.

Figure 49Defining lab process settings for build-deploy-test workflow

21. Save the updated workflow parameters by selecting the Finish button.

Figure 50Saving changes to the workflow parameters

22. Save the new build definition by pressing Ctrl + S.

23. It’s time to test out the new build-deploy-test workflow. In the Team Explorer – Builds view, right-click on the Build Deploy Test build and select the Queue New Build option.

Figure 51Queuing the build-deploy-test workflow

24. In the Queue Build window, use the default selections and select the Queue button to continue.

Figure 52Queuing the build-deploy-test workflow

25. Once the build is queued, double-click on the build in the My Builds section of Team Explorer to open it.

Figure 53Monitoring the build in progress

Note: It will take a few minutes for the build-deploy-test process to finish.

26. As the automated tests run in the test environment, you can watch the coded UI test execute on the VSALM2 virtual machine. You probably would not normally do this, as it is easy to interfere with the tests using the mouse and keyboard, so an alternative might be to enable the Video Recorder option when specifying the test settings.

Figure 54Coded UI test running in test environment

27. Once the build completes, view the summary to make sure everything succeeded as expected.

Figure 55Build Summary view

28. Now let’s make a change to the web application under test such that our automated tests fail. This will show how our build-deploy-test workflow could help us catch regression errors in the user interface.

29. In Solution Explorer, load Create.cshtml from the FabrikamFiber.Web project (located in the Views\Customers folder) and comment out the input button that has the value “Create” to simulate a forgetful developer accidently leaving in a change that breaks the user interface.

Figure 56Simulating a breaking user interface change

30. Save your changes by pressing Ctrl + S.

31. In the Team Explorer – Pending Changes window, select the Check In button.

Figure 57Check in changes

32. Back in the Team Explorer – Builds window, queue up the Build Deploy Test build definition once again and note that the updated site is built, deployed to the test environment, the coded UI test shows the missing button, and the build reports that the test failed as expected.

Figure 58Coded UI test running in test environment showing missing button

Figure 59Test run failed as expected

To give feedback please write to VSKitFdbk@Microsoft.com

Copyright © 2023 by Microsoft Corporation. All rights reserved.