Monthly Archives: February 2016

When Impersonation is useful

In a previous post I stated that Impersonation is not suitable for starting a Selenium browser session as a different user. Even so there are still a few scenarios where I do need it.

In my testcases I want to check that the state of the various tasks in SharePoint are conform my expectations. I use CSOM to query for the tasks and I verify that the results match the testcase. Due to SharePoint’s security trimming I can only see the tasks that I am authorized to see. As I don’t want my test user to have full site-collection admin privileges, I wrapped the CSOM calls in an Impersonation to another account that does have site-collection admin permissions. This lets me receive all relevant tasks regardless whether my account does or does not have permission to access to them.

The system I am testing will, in certain scenarios, set unique permissions on documents in a document-set. Even if I am the owner of the set, I will at most have Contribute permissions on those documents. Other users may or may-not have Contribute depending on the exact scenario. Therefore, my testcases need to check if the documents have the correct permissions. For this I use CSOM, however I cannot run that query under my own credentials as you need at least Design permissions to view the RoleAssignments and RoleDefinitionBindings of an object. So also here I wrapped the CSOM calls in a Impersonation to a site-coll admin.

‘Insert Call to webtest’ and the ‘Inherit Web Test Settings” property

One of the nice things in Visual Studio’s load test framework is the ability for a webtest to include calls to other webtests. This allows you to compose complex scenarios from a bunch of simple .webtests. In fact my load test uses statistical modelling to dynamically decide which tests its going to call.

If your webtest includes User Name / Password properties then you need to set the ‘Inherit Web Test Settngs‘ to True. Otherwise the called webtest won’t use the same credentials that the calling test is using. Especially in situations where you are running with Controllers and Agents you will probably need to set this setting.

Lets assume we have Webtest1 and it includes several calls to Webtest2. This has a few consequences you need to be aware of and deal with:

  1. Any WebTestPlugins in Webtest1 will execute when Webtest1 starts and each time Webtest2 starts. You probably don’t want that. Many people use the ‘Generate GUID’ plugin to store a unique ID in the context for the test session. However in this case the context parameter’s value will change every time one of the webtests is started. In my opinion its best to avoid using any WebTestPlugins on webtests that call to other webtests.
  2. Any validation rules in Webtest1 will also be applied to all requests in Webtest2. This can be problematic if webtest2 needs less or different validation.
  3. If webtest2 includes a call to webtest3, then webtest3 will also show the above issues.