Hands-On Lab
Lab Management Improvements in Visual
Studio 2012
Lab 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 onpremises 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 1
Launching 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 2
Test Controller Configuration
4. Click the Close button and exit without applying the settings.
Figure 3
Exiting 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 4
Launching 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 5
Location of home button
4. Click on the Change Project link.
Figure 6
Changing 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 7
Connecting to a team project
6. Select the Default test plan and then select the Select Plan button to continue.
Figure 8
Selecting 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 9
Navigating to the Lab Center in Microsoft Test Manager
8. Select the New button in the Environments section.
Figure 10
Creating 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 11
Creating 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 12
Adding 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 13
Adding 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 14
Moving 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 15
Configuring 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 16
Verifying 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 17
Starting 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 18
Status 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 19
Test 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 20
Microsoft 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 21
Starting Visual Studio 2012
4. Open the FabrikamFiber.CallCenter solution from the Dev branch in Source Control Explorer.
Figure 22
Source 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 23
Creating 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 24
Locating the existing test case
8. Double-click on the test case with title “Create new customer record” to open it.
Figure 25
Opening existing test case
9. Select the Associated Automation tab link.
Figure 26
Location of Associated Automation link
10. Select the ellipses (…) button to choose a test to use for automation.
Figure 27
Location of ellipses button
11. In the Choose Test window, select the CodedUITestMethod1 test and then select the OK
button.
Figure 28
Selecting test to use for automation
12. Select the Save Work Item button to save the test case.
Figure 29
Saving 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 30
Creating automated test settings
14. For the Name, enter “Fabrikam BDT Test Settings”. Next, select the Automated option.
Figure 31
Creating 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 32
Creating 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 33
Data 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 34
Advanced step for test settings
18. Select the Finish button to save the new automated test settings.
Figure 35
Creating automated test settings
Exercise 5: Creating and Running a BuildDeploy-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-deploytest workflow.
3. In Visual Studio, navigate to Team Explorer – Builds and select the New Build Definition link.
Figure 36
Creating 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 38
Creating 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 39
Disable 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 40
Creating 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 41
Creating a new build definition for build-deploy-test workflow
12. In the Process tab, select the Show Details button.
Figure 42
Creating a new build definition for build-deploy-test workflow
13. Select LabDefaultTemplate.11.xaml as the build process template.
Figure 43
Creating 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 44
Creating 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 46
Defining 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 47
Defining 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 48
Defining 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 49
Defining lab process settings for build-deploy-test workflow
21. Save the updated workflow parameters by selecting the Finish button.
Figure 50
Saving 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 51
Queuing the build-deploy-test workflow
24. In the Queue Build window, use the default selections and select the Queue button to
continue.
Figure 52
Queuing 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 53
Monitoring 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 54
Coded UI test running in test environment
27. Once the build completes, view the summary to make sure everything succeeded as expected.
Figure 55
Build 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 56
Simulating 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 57
Check 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 58
Coded UI test running in test environment showing missing button
Figure 59
Test run failed as expected
To give feedback please write to VSKitFdbk@Microsoft.com
Copyright © 2016 by Microsoft Corporation. All rights reserved.