Managing Browser Profiles when using Cross Browser testing in Coded UI Test

Saima_MSFT

February 21st, 20130 0

We introduced extended support in Coded UI Test for Cross Browser Testing with VS 2012 Update 2 February CTP (see this, this and this post for details). This post addresses details specific to managing browser profiles when using cross-browser testing feature.

Browser launches are often customized and you might want to test with specific user profiles. Sometimes, you don’t care about using specific profiles, but are forced to use a default profile. For instance,
if a profile is not specified, Chrome may think that it’s setting up the browser for first use and it displays some initial browser settings and you see the message “Chrome is almost ready”. This does not let you proceed with the tests.

Two commonly seen issues and their solutions are detailed below:

You don’t see your profile getting picked up.

Coded UI Test Picks up the profile the following way:

(i) If you have specified an argument of “–user-data-dir=<profile directory>” this is respected. Chrome will use this profile directory to launch your browser. (On details on what parameter to give for this command line see http://www.chromium.org/user-experience/user-data-directory)

Coded UI Code for this would look like:

BrowserWindow.CurrentBrowser = “Chrome”;

BrowserWindow.Launch(new string[] { “http://www.bing.com/“, @”–user-data-dir=C:Users<username>AppDataLocalGoogleChromeUser Data” });

(ii) If you have set Environment Variables for the folder path for the profile directories of Chrome/Firefox, these will be used. The Environment variable keys are:

“FireFoxProfileDirectory” – For Firefox

“ChromeProfileDirectory” – For Chrome

Set the above keys to the profile folder you want to get picked every time.

(iii) If neither of the above exists, a default temporary profile gets picked.

Your profile got picked fine, but you notice that multiple browser launches on Chrome do not proceed:

[You have used either (i) or (ii) of option 1 above], it’s due to a restriction that we cannot launch a second browser using the same profile directory. This is because the profile content gets locked and we cannot access it for another browser launch. This works just fine for FireFox, because the Selenium API internally will create copies of the profile directory specified. There are both pros and cons to the same – cached folders for a profile can become a pain, plus IO operation in folder copying consumes more time. If you need multiple launches of chrome in your test code, you can create your own temporary copies of the profile folder and use them as command lines. If you really do not care about what profile gets picked up, all is good – you need not set any environment variable or specify any command line argument, a temporary profile will get created for each browser launch.