Launching a Windows Store Application using Coded UI Test

This blog assumes that you have a prior understanding of Coded UI Test for Windows Store Apps. If not, Please read the "Introduction" blog of Coded UI Test for Windows Store Apps. This blog explains how to launch a Windows Store Application using Coded UI test.

API Definition and Usage:

In Visual Studio 2013, Users will be able create and test Windows Store XAML Apps using Coded UI Test. In Similar fashion to other technology controls, we have added XamlWindow, XamlButton, XamlTextBox etc. to test Xaml Windows Store Apps. To Launch a Windows Store App, we will be using "XamlWindow.Launch()" API:

XamlWindow.Launch(string appPackageFamilyName)

XamlWindow.Launch API takes a single argument which is  "appPackageFamilyName" and returns an object of XamlWindow. This XamlWindow object represents the window of Windows Store App that gets launched. 

AppPackageFamilyName:

XamlWindow Launch API takes a single argument which uniquely represents a specific Windows Store App. Package Family Name of a Windows Store App appended by its' App Id can uniquely represent a Windows Store App. These values are configured by the Application developers during App development. Coded UI Test recommends using Coded UI Test Builder for finding AppPackageFamilyName of a Windows Store App. Follow these steps to find the AppPackageFamilyName of a Windows Store App:

1. Pin the app's tile to the "Start Menu" if not already present.
2. Create a new Coded UI Test Project for Windows Store.
3. Launch Coded UI Test builder from the project.
4. Locate the App's Tile (shortcut key - CTRL + I) using Builder.
5. View the Properties of App's Tile in the builder and find Automation Id.
6. Copy Automation Id's Value to Clipboard.

Automation Id of the tile represents the "AppPackageFamilyName". This is the argument for the Launch API.

We will be using "File Picker" SDK sample from MSDN. As you can see in below image, Coded UI Test builder shows the automation id of the tile i.e. "AppPackageFamilyName" of the App. "File Picker SDK sample" tile is located using Builder and the Automation Id property shows the "AppPackageFamilyName". XamlWindow.Launch will launch the app if this string is given as parameter. Note that the app need not be pinned in start menu for Coded UI Test to launch the Application. Once you find the AppPackageFamilyName, you can unpin it from the Start Menu if you wish to do so. 

Example:   Automation Id here is "Microsoft.SDKSamples.FilePicker.CS_8wekyb3d8bbwe!FilePickerSample".  

 XamlWindow.Launch("Microsoft.SDKSamples.FilePicker.CS_8wekyb3d8bbwe!FilePickerSample");

Launch API Behaviour:

1. XamlWindow.Launch API launches the Windows Store app as soon as the method is called. This call will wait for "Application" Splash screen to disappear unless the splash screen takes too much time. At the most, Call will wait until the "WaitForReadyTimeout" value and returns immediately. Please note that the API does not throw any exception even If the call times out while waiting for the splash screen to disappear. 
2. Behavior of Launch API is dependent upon the Application State as well. If the application is not launched previously (i.e. in this session after the machine started - not in memory), then the Application will be launched afresh. If the app is already Opened(might be minimized/suspended) , then the behaviour is dependent upon the application. Every Windows Store Application will implement the "Activated" event. Application Developer will decide the behavior of this event by its implementation. If the application developer intended the "activated" event to restore app's state, then the Launch API will launch the app as the developer intended. Coded UI Test cannot or perhaps should not control this behaviour of application. This is up-to the application developer. 
3. If the "AppPackageFamilyName" parameter is incorrect or the app is not installed, then the API will throw "PlaybackFailureException" with the error message relaying the same i.e. "Application is not registered"
4. After the test completion, Coded UI Test always closes the windows store applications that were launched as part of the test using this Launch API. If the user desires to leave the apps open after test completion, he/she should set "CloseOnPlaybackCleanup" to false on the XAML window object. If user intends to close the application explicitly, he/she can call Close() API on application window object.

1.  XamlWindow appWindow = XamlWindow.Launch("Microsoft.SDKSamples.FilePicker.CS_8wekyb3d8bbwe!FilePickerSample");
    appWindow.CloseOnPlaybackCleanup = false;

Usage Scenarios:

1.  Let us take a scenario where Coded UI Test launches the app afresh i.e. the app was not launched previously after the login.  Application will be launched afresh. We will launch the app as below:

 XamlWindow.Launch("Microsoft.SDKSamples.FilePicker.CS_8wekyb3d8bbwe!FilePickerSample");

 2. Now, Let us do some actions in the application manually and minimize it. Click on "3) Pick a folder" option and pick "Documents" folder. It should look like this:

  3. If we launch the App again using the API, then it will just launch the minimized app in the same state as above screenshot. This is because the "Activated" event of the app does not bring the app to fresh state which is what the developer intended for this app.

  4. If we close the app's window object using "Close()" API and call the Launch API again, it will launch the App afresh as in the first screenshot.

 XamlWindow appWindow = XamlWindow.Launch("Microsoft.SDKSamples.FilePicker.CS_8wekyb3d8bbwe!FilePickerSample");

 Playback.Wait(2000);
 appWindow.Close();
 Playback.Wait(1000);

 XamlWindow.Launch("Microsoft.SDKSamples.FilePicker.CS_8wekyb3d8bbwe!FilePickerSample");

  5.  In some scenarios, an action in a store app can launch another store application like for example, opening a Mail client or a sharing app. The second app that was launched by some action might get closed immediately after its use and brought up again whenever it is required. In these cases, the XamlWindow object of the second app should have "AlwaysSearch" option to be set on it. Reason being that the second app might get automatically closed and reopened multiple times and so, the app window object can become stale causing issues. "AlwaysSearch" option tells the Coded UI test to search for the window again. 

Mouse.Click(someButton); // Launches another app
XamlWindow secondAppWindow = new XamlWindow();
// Configure Search properties of the newly launched window here or use Coded UI Test Builder to capture these properties
secondAppWindow.SearchConfigurations.Add(SearchConfiguration.AlwaysSearch);