The default bucketsize (no of tests assigned to each agent per run) is 100. So if there are 400 tests and 6 agents, 100 tests each would be given to 4 of agents. The last 2 agents would be utilized. Reducing the bucket size is the option to utilize all the test agents in an environment. The option though is not exposed in the  testsettings UI in Microsoft Test Manager (MTM).

You can use the utility mentioned in the blog http://blogs.msdn.com/b/aseemb/archive/2010/08/06/update-testsettings-utility.aspx for updating this info. In case of non-TFS remote runs, the testsettings file can be edited in the xml editor itself.

Some more info on this issue,

http://blogs.msdn.com/b/vstsqualitytools/archive/2010/10/24/test-agent-test-controller-and-mstest-faq.aspx (FAQ #24)

When a test agent connects successfully with a test controller, it also registers collectors that it had discovered. However when these collector are removed from the agent, they don’t get unregistered and linger on in the TFS. There’s no UI to achieve the same today. The below piece of code comes handy in unregistering a collector.

TfsTeamProjectCollection tfsCollection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri(<TFS Server>));

            ITestManagementService testManagementService = tfsCollection.GetService<ITestManagementService>();

            List<IDataCollectorInformation> unregister = new List<IDataCollectorInformation>();

            foreach (var collectorInfo in testManagementService.DataCollectors.Query())

            {

                if (<condition to match the collector to be marked for unregister>)

                {

                    unregister.Add(collectorInfo);

                }

            }

            if (unregister.Count > 0)

            {

                testManagementService.DataCollectors.Unregister(unregister);

            }

subst <drivename> %windir%\assembly

Example: subst z: %windir%\assembly

Now z: has GAC directory mapped with a folder view.

However there is a config that can be tweaked to reduce the hovers as per the need of individual web apps. The general logic followed to record hover is to look for  css property changes that can cause a display change (style.display changing from “none” to a valid value indicates that a control has become visible). When such a property change occurs, a mouse hover is recorded over the control over which the mouse is present at that instant. Now the window during which we look for such property changes should ideally be between when the mouseover event (the user moves into a control, say a menu item) and the next mouse move event. But different implementations of menus exist, example one which creates a timer based execution tin the onmousehover eventhandler to show a submenu in a delayed manner. There are other cases where onmousemove handlers have been used to show submenus). As a result there’s no restriction on the window during which we look for these display property changes in the engine implementation. However you can tweak it using the a OR’ed value of the below values as per the need of the individual apps to reduce hovers.

<add key=”ImplicitHoverLevel” value=”1”> No hovers will be recorded.

<add key=”ImplicitHoverLevel” value=”14”> (OR’ed 2,4,8 will not consider css classname change for recording hover, plus will look for hover changes within a restricted window of mousehover event and mouse move event)

The above key needs to be set in the CodedUITestBuilder.exe.config or mtm.exe.config (depends on the client that’s being used for recording).

ImplicitHoverLevel
{
    /// <summary>
    /// Default
    /// </summary>
    Default = 0,

    /// <summary>
    /// Hover script won;t be added
    /// </summary>
        DoNotRecordImplicitHover = 1,

    /// <summary>
    /// CSS Classname changes will be ignored
    /// </summary>
    IgnoreClassNameChanges = 2,

    /// <summary>
    /// Property changes in Mouse move will be ignored
    /// </summary>
        IgnoreMouseMoveChanges = 4,

    /// <summary>
    /// Property changes post mouse hover (like using timer to change the property)
    /// will be ignored
    /// </summary>
        IgnorePostHoverChanges = 8,
}

When a automated test run queued from MTM or using the Build Deploy Test workflow is executed by the controller the data collectors are enabled as part of this run. At the end of a test run the data collectors also send back the data through messages and this gets stored at the controller. If the test run is for a longer duration, some of the files send by the data collectors increases in size proportionally (intellitrace). This was causing the Controller to run out of space pretty quick.

Both Microsoft Test Manager and Visual Studio have an option to delete temporary folders at the Controller, but it doesn’t delete the data from TestRunStorage. However there’s an option to complete turn off job spooling. Open QTController.exe.config from the Visual Studion install location (<installdir>\Microsoft Visual Studio 10.0\Common7\IDE) and set the value of the flag “ControllerJobSpooling” to false and restart the controller service.

The main intention behind this blog is to share my knowledge and learnings with fellow developers out there.