1. No category

Automating Coded UI Testing
using Microsoft Testing Tools
in Visual Studio 2012
Clive G Hermann
Introductions
•
Name
•
Title/Function
•
Job Responsibility
•
Testing Experience
•
C# Experience
•
Expectations for the Course
Course Materials
Course Contents
1. Overview of Automated Code UI Testing
2. Walkthrough steps from beginning-to-end
3. Creating Manual Tests
4. Creating a coded UI test Using Coded UI Test
Builder
5. Automating Coded UI Test Cases
Course Contents
2
6) Data Driven Coded UI Tests
7) Anatomy of Code UI Tests
8) Introduction to Lifecycle Management
9) Extending Coded UI Tests and Action Recordings
10) Testing Large Applications with Multiple UI Maps
11) Using HTML5 Controls in Coded UI Tests
12) Visual Studio 2012 ALM Features
13) Upgrading Coded UI Tests from Visual Studio 2010
Course Contents
3
14) Using WPF with Coded UI Tests
15) Best Practices for Coded UI Tests
16) Using the Coded UI Test Logs
17) Using SharePoint with Coded UI Tests
18) ExcelCodedUIHelper
1) Overview of Automated
Coded UI Testing
1) Overview of Automated Code
UI Testing
 UI Testing
o Functional Testing
 Controls
 User Interface
 Whole Application
 The earlier we catch a “bug” or potential problem the less it
costs!
o Image
o Manpower
Reality of Automated Testing
 70% of all Testing is manual
What is
Coded UI Testing
 Replacing a Manual User Interface Test with an Automated
Test.
o To Allow:
 Replication
 Consistency
 Regression Testing For:
• Multiple Environments
• Multiple Versions
IT Has a Problem
Test Early and Often
 Catching defects as early as possible is the least expensive way
to ensure software quality.
 Kent Beck and Cynthia Andres wrote
o "Here is the dilemma in software development: defects are
expensive, but eliminating defects is also expensive”.
o “However, most defects end up costing more than it would have
cost to prevent them."
The Testing Trends
Forwards
 Test-Driven Development
o Design the Test
o Then Write the Code
The Testing Trends:
Backwards and Circular
Linking it all together
o Help-Desk
o Test
o Story Board
o Task
o Unit
o Programmer
The Ultimate Goal
of Software Testing
 To find the bugs before your users do!
o UI Testing is END USER TESTING
o OR TOTAL SYSTEM TESTING
o OR INFRASTRUCTURE TESTING
Manual to Coded UI
Testers’ Multiple Roles
 Guarantee SOFTWARE QUALITY
 Regression Test each Version or Build
 Test all Environments
 Provide Developers with all the information required:
o To REPRODUCE THE “BUG”
o Trace the steps to get the BUG
o Screen shots, IntelliTrace, Logs and Stack Traces
 NO-REPRO must be ELIMINATED
Tiers of Software Testing
 Clear Separation of Functions
 Clear Definition of Communication and Collaboration
 TEAM of Software Quality
Module 2
Walkthrough steps from
beginning-to-end
2)Walkthrough steps from
beginning-to-end
 Lesson 1 Manual Testing
o
o
o
o
Using Microsoft Test Manger to create and manage Test Plans
Running Test Cases and Publishing Results
Conducting Exploratory Testing
Fast Forward for Manual Testing
 Lesson 2 Coded User Interface Testing
o
o
o
o
Automated Functional Tests – Using CUIT
Create a CUIT from Scratch
Create a CUIT from action recording
Making CUIT more Robust and Flexible
A manual testing process
Building an App
For Manual Testing
 Demo of Simple Calculator
Automating the Calculator
 Demo
Adding Data
 Demo
Introducing an Error
 Demo
Lab 1
 The Calculator
3 Creating Manual Tests
Visual Studio 2012
Supported Test Types
Microsoft Test Manager
 Provides a single environment to author and manage Tests
Quick Start Guide for Manual Testing
using Microsoft Test Manager
 http://msdn.microsoft.com/en-us/library/dd380763.aspx
Easily reproducing issues through
manual testing
 Introducing Managed Exploratory Testing
 The 5 Minute “elevator” Video
 http://channel9.msdn.com/Series/Visual-Studio-2012Premium-and-Ultimate-Overview/Visual-Studio-Ultimate2012-Easily-reproducing-issues-through-manual-testing
4) Creating a coded UI test
Using Coded UI Test Builder
4) Creating a coded UI test Using
Coded UI Test Builder
 Test Types
 Microsoft Test Manager
 Exploratory Testing
 Easily reproducing issues through manual testing
Test Types
Authoring a TEST case
 Demo
 Lab
Microsoft Test Manager
 The first time you run MTM it will prompt
o Add Team Foundation Manager
 “If you don’t know the Name, contact your administrator”
 It might require “ServerName:Port Number”
TFS and MTM
Connecting Microsoft Test Manager to
TFS
 MTM is always connected to TFS
Test Plan Properties
Figure 21-5.
Test plan properties
MTM Test Suites
 Static suite: The content of this suite is manually added test
cases.
 Query-based suite: A query-based suite lists all test cases
matching a given work item filter.
 Requirements-based suite: This suite shows the test cases
associated with a selected TFS requirement.
Configuring Test Settings
 Establish Environments
 Diagnostic Connectors
 Best Practice
o Work with Development Teams
o The Developers need to have the same tools to view the test data
you collected for them
 Microsoft released a “Test Attachment Cleaner” available at
o “Aka.ms./TFPowerTools”
Using Builds
 Scout
o Installing Software and running some initial tests
o After the SCOUT is successful it can become a “template for
other Testers”
 There is an available builds DROPDOWN
 Click “ASSIGN TO PLAN” to add a new build to a plan
Analyzing Impacted Tests
 Quickly identify tests that need to be run based on changes to
code
 Can Run in the background
 “Track” menu => Recommended Tests
o Does not recognize “DATA” changes
o Does not recognize other library changes
o Does not recognize other Application changes
 Best Practice - Periodicaly run all Tests
Defining Multiple Test Configurations
 Environments may differ:
o IE 8,9,10
o Ipad Horizontal/Vertical
o BYOD
o HTML5
o
ETC.
Test Cases are organized in to Suites
 Requirements-Based test suite
 Query-Based test suite
 Static Test Suite
o Status of tests in TEST SUITE
 In planning
 In Progress
 Completed
Types of Tests
1 – Unit and Component Tests
2 – Functional Tests
3 – Exploratory Testing
4 – Capability Testing
Unit and Component Tests
 Unit and component tests are automated tests written to help
the team develop software effectively.
 With good suites of unit and component level tests we have the
safety net that helps us develop software incrementally in short
iterations without breaking existing functionality.
 Invaluable when refactoring code. With good test coverage a
developer should feel confident to make a change without
knowing all about every dependency.
 The tests should tell us if we did wrong
Lab
Functional Tests
 Functional Tests
 Functional tests are mainly our traditional scripted system tests
in different flavors.
 It is hard to avoid running these tests manually at first, but we
should try to find ways to automate them as we learn more
about our product and how it needs to be tested.
 Many functional tests can be automated and then we can focus
on early testing for the manual tester
Exploratory Testing
 Exploratory testing is a form of software testing in which the
individual tester can design and run tests in a freer form.
 Instead of following detailed test scripts, the tester explores the
system under tests based on the user stories
 As the tester learns how the system behaves the tester can
optimize the testing work and focus more on testing than
documenting the test process.
Capability Testing
 Lastly we have the capability tests.
 These tests are run against the behavior of the system;
o we test non-functional requirements
o Performance
o Security
 These tests are generally automated and run using special
purpose tools, such as load test frameworks and security
analyzers.
Exploratory Testing
 We should leave this category of tests as manual tests.
 The focus should be to catch bugs that would fall through the
net of automated tests.
 A key motivation for automated testing is to let do more of
exploratory and usability testing because these tests validate
how the end-user feels when using the product.
Story Boards

A user story can be stated as simply as

As an Employee I want to have an efficient way to manage my expenses.

The conversation around this statement between the product owner and the
development team can raise questions such as:

Who can submit expense reports?

What states can an expense report be in?

When is it possible to change or remove an expense report?

What data is required in an expense report to register it correctly?

Where are the expense reports stored? For how long?
Adding Detail to User Stories
 An expense report has the following state model:
 New when created
 Pending after submitted for approval
 Approved
 Rejected
Story Boards are Vital to Testing
 Allows the Tester to Verify what should happen
 If this does not Happen
o See the Tasks that were assigned to this requirement
o See the Programmers assigned to Each Task
o Notify the Developer(s)
 Provide the necessary info to avoid “NO REPRO”
 Add this Test to the “Suite”
Lab
 Introduction to Test Planning with Microsoft Test Manager
2012
6 Data DrivenTests
6 Data Driven Tests
 Any Files Used in The Tests
 Example XML to load Variable and Expected Data
 Could be:
o SQL
o Business Connectivity Services
o SharePoint Lists
o SQL Reports
o Excel / PowerPivot
o SSAS
Uses of Data Driven Tests
 Create errors
 Add new Cases
 Modified the rows
 Automation can be changed by using different files
Lab - How to Create a Data-Driven
Coded UI Test
7) Anatomy of Coded UI
Tests
7) Anatomy of Coded UI Tests
 When you create a Coded UI Test, the Coded UI Test Builder
creates a map of the user interface under test, and also the test
methods, parameters, and assertions for all tests. It also creates
a class file for each test
 http://msdn.microsoft.com/en-us/library/ff398062.aspx
7) Anatomy of Coded UI Tests
 When you create a Coded UI Test, the Coded UI Test Builder
creates a map of the user interface under test, and also the test
methods, parameters, and assertions for all tests. It also creates
a class file for each test
 http://msdn.microsoft.com/en-us/library/ff398062.aspx
7) Anatomy of Coded UI Tests
 When you create a Coded UI Test, the Coded UI Test Builder
creates a map of the user interface under test, and also the test
methods, parameters, and assertions for all tests. It also creates
a class file for each test
 http://msdn.microsoft.com/en-us/library/ff398062.aspx
The UNFORTUNATE REALITY
 70% of all Application Testing is MANUAL
8) Introduction to
Lifecycle Management
Visual Studio 2012
 Visual Studio Ultimate, Visual Studio Premium and Test
Professional include a Microsoft Test Manager
o to help you define and manage your testing effort by using test
plans.
o You create a test plan and add any test suites, test cases, or
configurations that you need
Visual Studio 2010 to 2012
Completely Restructured
Software Testing
 In 2012 Visual Studio Improves:
o Integration between testing and the rest of the Software
Development lifecycle
o Example – Better handoff from tester to developer
o Less NO REPRO
o Improved build-deploy-test workflow
o Improved Virtualization
Types of Test
Supported by VS 2012
 Manual Tests
 Coded UI Tests
 Unit Tests
 Web Performance Tests
 Load Tests
 Generic Tests
 Ordered Tests
Testing Pyramid
Testing Structures
Using Shared Steps
 Demo
 LAB
Assigning Configurations
 Demo
Manual Tests
 Require a Human to Interact with an application
 Verify some expected result
 Report on the success of the test
Coded UI Tests
 Provides the Capability to author tests that automatically
interact with user interface
 Verify Results
 File Bug Report
 It can be run Frequently without human intervention
 Typically more expensive to author and maintain than manual
test
Unit Tests

Used by Programmers for Programmers

Quickly becoming the standard practice

A vital part of Test-Driven Development

Generally focus on a lower level than other Testing

Ideally a unit is the smallest atomic part - One method of One object

Test written before the object

It will initially fail

o
Correct
o
Re-test
o
Refactor
o
Repeat
Essential component of Regression Testing
Web Performance Tests
 Verify that the web site is behaving as expected
o Add load to see if the application is still capable of Scaling
Load Tests
 Tests that Application Scales and Performs as Necessary
Generic Tests
 Calling external testing systems
 Results can be automatically parsed to determine success
 Could be simple console application to XML document
exported from LOB
Ordered Tests
 Container for other tests
 Specific order of tests
 Some run more than once
Diagnostic Data Adapters
 The Key challenge of Testers
 Provide Developers with sufficient information to reproduce
the problem
 Most Bugs result in No Repro
 “It Works on my machine”
Diagnostic Data Adapters
 A Diagnostic Data Collector is responsible for collecting data about the
machine under test
o
o
o
o
o
o
o
o
o
Action Log
ASP.NET Profiler
Code Coverage
IntelliTrace
Event Log
System Information
Test Impact
Video Recorder
Network Emulation
Developers view
 Test-Driven Development
 Unit Testing
Test-driven development (TDD)
WikiPedia
 Is a software development process that relies on the repetition
of a very short development cycle:
 First the developer writes an (initially failing) automated test
case
o That defines a desired improvement or new function
o Then produces the minimum amount of code to pass that test
o Refactors the new code to acceptable standards
Tester’s View
 Not Unit Testing
 Not Integration Testing
 Not Regression Testing
 Whole Application Testing
Requirements-Driven Testing
 When requirements or user stories, or features are ready to be
tested, you can run your tests for each configuration that you
specified
 UI – User Interface Testing
 Usability - Testing
•
Test Runner: The Test Runner from MTM can create action recordings from a manual
test. The action recording can later be used to play back the test session in MTM or to
generate a Coded UI test from the recorded steps.
•
Coded UI Test: The implementation of the actual test written in C# or VB.NET. The
Coded UI Test is either generated by the Coded UI Test builder code generator or coded
directly against the Coded UI Test API.
•
Test Recorder: Records actions from a test session, which then can be used by the Test
Runner to automate a generated test or by the coded enerator to create a Coded UI test.
Coded UI Test API: The Coded UI Test API can be used to create UI tests which are more
tightly connected to the UI elements
•
Technology Managers. These are the core components responsible for mapping UI
elements to the underlying technology (i.e. web browser or a rich client). We can
implement custom plug-ins to support platforms which the native plug-ins does not
support.
Managing Automated Tests
 These tests are critical to project success
 The number keeps growing
 Regression testing is vital
 Sometimes hundreds or even thousand of tests

Supported Platforms


As we can see from the architecture overview, the Coded UI tests require support from the platform being tested. For Visual Studio 2012
the following platforms are supported for Coded UI tests as well as action recordings:

•Internet Explorer 8, 9, 10.

•Windows Forms 2.0 and later

•WPF 3.5 and later

•Windows Win32 (not officially supported but may work)

•MFC (partially)

•SharePoint (partially)

•Dynamics CRM

•Citrix/Terminal Services (partially)

•PowerBuilder (partially)
 A common requirement of automated tests is to be able to run
the test a number of times with different parameters. In Chapter
16 we looked at how we can work with data-driven test in
details. The same techniques are valid for coded UI tests as
well except that the data source for a UI test often points to the
data set managed in the associated test case. Using the test case
to manage test data for the automated test is nice because then
the tester can update the data directly from inside MTM.

Coded UI tests are probably the ideal type of test for regression testing because they give
us the opportunity to automatically test the system just like a real user would. But there
are a number of issues that make UI tests difficult as a general purpose solution for
automation solution, including

•Requires a UI.

•Requires a desktop session to run.

•UI tests are more complex to design and maintain.

•Difficult to scale.


To work around these challenges we generally recommend considering “under-the-UI”
tests as a complement to the UI tests. These tests could be written against the APIs in the
system or against the controller layer in an MVC style of application.

Another option for running tests from the command-line is to use the Test Case Management command-line tool,
TCM.exe. This tool is installed under

C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\TCM.exe

There are several options for us to start a test run, for instance:

•Run all tests in a test suite. Locate the Suite Id from the test suite in MTM. tcm run /create /title:"UI Test Run"
/planid:5 /suiteid:11 /configid:2 /collection:http://tfs.kangreen.com:8080/tfs /teamproject:"Expense Reporting"

You can use tcm.exe to figure out the Ids for plans, suites, and configurations as well:

•List plans tcm plans /list /collection:http://tfs.kangreen.com:8080/tfs /teamproject:"Expense Reporting"

•List suites Tcm suites /list /collection:http://tfs.kangreen.com:8080/tfs /teamproject:"Expense Reporting"

•List configurations tcm configs /list /collection:http://tfs.kangreen.com:8080/tfs /teamproject:"Expense Reporting"
Demo Creating a Test Project
 http://channel9.msdn.com/Series/Visual-Studio-2012Premium-and-Ultimate-Overview/Visual-Studio-Ultimate2012-Easily-testing-user-interfaces-with-Coded-UI-tests
Components of a Test Plan
Benefits of Automated Testing
 Automated tests can quickly test whether your application is
still working correctly after code changes have been made to
your application
 Automating Test should not take more than about 40% of team
members' time
The Achilles’ heel of automated
tests
 The problem with user interface tests is not in how to execute
them, but what to test.
 Since human testers would often check the whole round-trip of
information, from the GUI to the back-end report
 First instinct is to replicate that and try to verify business
domain rules. This is the Achilles’ heel of UI tests, and it
ultimately leads to enormous waste of time.
UI Testing without shooting
yourself in the foot
http://gojko.net/2010/04/13/how-toimplement-ui-testing-without-shootingyourself-in-the-foot-2/
Thinking About These Different Levels
 The idea of thinking about these different levels is good because it
allows us to write
 UI-level tests that are easy to understand,

efficient to write
 relatively inexpensive to maintain
 Checking that delivery is available for two books involves putting a
book in a shopping cart. Putting a book in a shopping cart involves a
sequence of technical steps. Entering address details does as well.
Breaking things down like that and combining lower level concepts
into higher level concepts reduces the cognitive load and promotes
reuse.
Using Microsoft Test Manager
 You can plan, manage and execute both manual and exploratory
tests.
 You can also automate your manual tests after they are stabilized.
 While you are performing manual and exploratory tests, you can log
bugs.
o The bug will contain a trace of your recent actions, a snapshot of the
state of the system, and a copy of any notes you made while exploring
the system. You can record your actions in the test case, so that they can
be played back on later occasions.
Manual to Coded UI

With Visual Studio 2012 Lab Management it is possible to create an
environment based on existing infrastructure without installing SCVMM. This
is great because we can now start using Lab Management without any
additional installation required. The lab machines in a standard environment can
be physical or virtual (or both) and the virtual machine does not have to be
managed by SCVMM or Hyper-V.


To create a standard environment you only need to know the names of the
machine you want to add to the environment and a user account to be used to
log in and deploy the test agent service onto the machine.


A standard environment can be connected to directly from MTM and the Test
Runner making the integration with lab environments really smooth.

The alternative to standard environments is to use a SCVMM environment. The key
features of a SCVMM environment include

•Create new machines from templates. New lab machines can automatically be created
by anyone (having permissions) running MTM. It is no longer required to send a request
to the operations department to get machines created for a new environment or to do
other maintenance operations such as starting, stopping, snapshotting, or restoring
machines.

•Support for snapshots. It is possible to work with snapshots from MTM, which enable
testers to save state during testing. This is a powerful feature both to unlock the tester if a
test case fails (no need to block an environment while waiting for a resolution) but also to
give a developer a fixed point in time to reproduce a bug.

•Connection inside MTM. A SCVMM environment can be connected to MTM and the
Test Runner just like with the standard environment.

There are a number of metrics to can use as KPIs for software testing.

•Number of bugs per state. How many bugs do we have that are active, resolved, or closed? Are the number of
active bugs increasing and number of resolved and closed bugs constant? Then we need to look into how we perform
our testing.

•Number of bugs sent back from testers for more information. A large number might indicate that communication
between developers and testers must improve.

•Code coverage. This shows us how much of the code has been covered by our automated unit tests. We get the
value as a percentage of the whole code.

•Tests run results. How are our tests performing? Do we have many failed tests? If so, what can we do to improve
this?

•Percent Requirements covered by test cases. Do we write test cases for all our requirements? If not, what is the
reason?

•Percent Requirements covered by testing. Do we actually run the tests we have test cases for? If this figure is low
and the figure for Percent Requirements covered by test cases is high we might have an issue we need to deal with.

The application tier is the core of TFS. Here we find all services TFS offers.


First we find all web services for team project collections. We all recognize this so no further explanation is necessary:

•Version control

•Build service

•Lab management

•Work Item tracking

•Team Foundation Framework services.


This set of services is running on the Application Tier of TFS and allows us to access the different aspects of Team Foundation Server,
including administration, security, and events. They enable us to extend Team Foundation functionality by developing TFS extensions and
adapters to integrate third-party tools with TFS 2012.


We also find the Application Web services:
The Tester’s Benefits

After you have run your tests, you can report on your progress. When you use test plans
to structure your testing approach, you can answer the following questions:

How many tests have passed or failed?

How many tests still have to be run for this iteration?

When will the testing be complete?

Which areas of the product have high test failure rates?

Which test configurations have high test failure rates?

Who has the most tests left to be run?

Can resources be reallocated to better balance the remaining testing?

Which build should the testers be using based on code changes and bug fixes?
Essential Guide for Running
Automated Tests from a Test Plan
Creating a CUIT
 Coded UI Test
 You perform the test manually while CUIT Test Builder runs in
the Background
 You can Specify the Values that should appear in specific fields
 The CUIT Test Builder Records actions and generates Code
 Your Main Skills are in Testing not Coding
If you are a Developer
 You can extend the CUIT code
 The CUIT Test Builder builds Structured Code
 Straightforward to copy and adapt
Required Software
 Visual Studio Ultimate, Visual Studio Premium
The 3 Major UI Test Types
 Planned
 Exploratory
 Load and Muli-user
Defining Your Testing Effort Using
Test Plans
Microsoft Test Manager enables you to do three important tasks, as shown in the
following illustration:
Exploratory testing
 Exploratory testing seeks to find out how the software actually
works, and to ask questions about how it will handle difficult
and easy cases. The quality of the testing is dependent on the
tester's skill of inventing test cases and finding defects. The
more the tester knows about the product and different test
methods, the better the testing will be.
Benefits
of
Exploratory Testing
 The main advantage of exploratory testing is that less preparation is needed,
important bugs are found quickly, and at execution time, the approach tends
to be more intellectually stimulating than execution of scripted tests.
 Another major benefit is that testers can use deductive reasoning based on
the results of previous results to guide their future testing on the fly
 Another benefit is that, after initial testing, most bugs are discovered by
some sort of exploratory testing. This can be demonstrated logically by
stating, "Programs that pass certain tests tend to continue to pass the same
tests and are more likely to fail other tests or scenarios that are yet to be
explored.“
 WikiPedia
DrawBacks
of
Exploratory Testing
 Disadvantages are that tests invented and performed on the fly can't
be reviewed in advance (and by that prevent errors in code and test
cases), and that it can be difficult to show exactly which tests have
been run.
 Freestyle exploratory test ideas, when revisited, are unlikely to be
performed in exactly the same manner, which can be an advantage if
it is important to find new errors; or a disadvantage if it is more
important to repeat specific details of the earlier tests. This can be
controlled with specific instruction to the tester, or by preparing
automated tests where feasible, appropriate, and necessary, and
ideally as close to the unit level as possible.
Exploratory Testing
 Exploratory testing is particularly suitable if reuirements and
specifications are incomplete, or if there is lack of time.[7][8]
The approach can also be used to verify that previous testing
has found the most important defects.[7]
Visual Studio and Exploratory Testing
 Performing Exploratory Testing Using Microsoft Test
Manager
In Microsoft Test Manager
open Testing Center
Test
Do Exploratory Testing
I don't see
“Do Exploratory Testing”
Your team is using a version of TFS prior to 2012.
Lesson 2 Coded User Interface Testing
o Automated Functional Tests – Using CUIT
o Create a CUIT from Scratch
o Create a CUIT from action recording
o Making CUIT more Robust and Flexible
Contents of a Coded UI Test
When you create a Coded UI Test, the Coded UI Test Builder creates a map
of the user interface under test, and also the test methods, parameters, and
assertions for all tests. It also creates a class file for each test.
5) Automating Test Cases
 Automating the Calculator
 Planning and Tracking
 Architecture, Modeling, and Design
 Developer Tools
Testing
 Team Foundation Build
 Version Control
Testing
New in VS 2012

Conduct exploratory test sessions.

Locate, view, and edit your test methods, UI actions and their associated controls in the
UI control map.

Quickly track your test plan progress using the Results tab in Microsoft Test Manager.

Clone your test plan to work on different releases in parallel.

Test Windows Store apps running on a remote device using manual tests or exploratory
test sessions.

Install and configure agents more easily for Lab Management for Visual Studio 2012.

Include SCVMM 2012 and clustered Hyper-V hosts in Lab Management for Visual
Studio 2012.
10) Upgrading Coded UI Tests
from Visual Studio 2010
SOA
11) Extending Coded UI Tests and
Action Recordings
 Planning and Tracking
 Architecture, Modeling, and Design
 Developer Tools
 Testing
 Team Foundation Build
 Version Control
12) Testing Large Applications
with Multiple UI Maps
13) Using HTML5 Controls in
Coded UI Tests
14) Using WPF with Coded UI
Tests
15) Best Practices for Coded UI
Tests
16) Using the Coded UI Test Logs