Rituparna's Bloghttps://blogs.msdn.microsoft.com/rituparna
Rituparna's Blog on Life @ Microsoft and outside ;)Sun, 06 Dec 2009 01:46:00 +0000en-UShourly1Installing Windows Automation API 3.0 for enabling CodedUITest on WPF Applicationshttps://blogs.msdn.microsoft.com/rituparna/2009/12/06/installing-windows-automation-api-3-0-for-enabling-codeduitest-on-wpf-applications/
https://blogs.msdn.microsoft.com/rituparna/2009/12/06/installing-windows-automation-api-3-0-for-enabling-codeduitest-on-wpf-applications/#commentsSun, 06 Dec 2009 01:46:00 +0000https://blogs.msdn.microsoft.com/rituparna/2009/12/06/installing-windows-automation-api-3-0-for-enabling-codeduitest-on-wpf-applications/If you are using CodedUITest to test WPF applications then installing Windows Automation API 3.0 is a pre-requisite. Without this the virtualized controls in WPF wont be played back correctly and since lot of the WPF controls like ListBox/Datagrid are virtualized by default , this will lead to failures.

Windows automation API is pre-installed on WIN7 and can be installed on Vista/XP as well. This blog has all the details on howto get Windows Automation API 3.0 installed.

In case the machine does not have WAA3.0 code generated on doing action on WPF application will have the following comment

try
{
vsttTrackHover.NodeAddition();
vsttTrackHover.OverrideNodes(domElement.parentNode.all, 0);
}
catch (ex)
{
}
}">Mouse Hover is an important part of a Application WorkFlow. Hovering on a control brings about changes in the application which leads to Controls appearing/disappearing , Properties of the controls being changed ,new windows coming up etc. Needless to say it is pertinent that all the Hover Actions are identified correctly during recording to ensure a proper Playback.

IMPLICIT HOVER

For recordings on WEB Applications CodedUITest intelligently identifies that an Hover action has been performed on the application and records a Hover-Action on the control on which the Mouse was hovered . This type of auto-generated Hover-Action is referred to as IMPLICIT HOVER. The action such generated was not explicitly performed by the User (however not recording the action would most certainly lead to a faulty recording) and as such is tagged with the ContinueOnError flag. This indicates that even if the action is not played back the Test wont fail and execution will pass on to the next Step. The code generated for Implicit Hovers will look like

// Set flag to allow play back to continue if non-essential actions fail. (For example, if a mouse hover action fails.) Playback.PlaybackSettings.ContinueOnError = true;

// Reset flag to ensure that play back stops if there is an error. Playback.PlaybackSettings.ContinueOnError = false;

Implicit Hover is a very cool feature in CodedUITest and greatly improves User experience.

The Implicit Hovers can be turned off by modifying the CodedUITestBuilder.exe.config and changing the value of the RecordImplicitHover key. By Default it is turned ON.

<!–Use this to enable/disable recording of implicithovers.–> <add key="RecordImplicitHover" value="true"/>

This can be similarly turned OFF in the Fast-Forward a Manual Test scenario by updating the mtlm.exe.config.

EXPLICIT HOVER

For Client Side Applications Hover-Actions are not recorded implicitly. User has to record the Action Explicitly by Hovering the Mouse on the desired location and pressing a combination of keys to record the Hover-Action. The default Key combination are CTRL + SHIFT + R. The default value can be changed by updating the config files as mentioned above. Explicit Hovers are actual User Actions and are not marked with ContinueOnError flag as a result.

ThinkTime by definition is the time spent by a User thinking about his next step. This has been leveraged in VSTT CodedUITest and Fast-Forward a Test feature in MTLM (as also in VSTT Web Test) to make the Playback more resilient.

If the ThinkTime is turned ON then the delay between each actions is identified and stored in the XML (for MTLM ) incase the delay is greater than a User Specified Interval (ThinkTime Threshold). In CodedUITest an function Call with the ThinkTime Interval is added.

During Playback RnP will wait for the ThinkTime Interval for the action before doing the Playback for that action. This will ensure that if waiting for that particular instance sparks off a particular change in the Application (Or the Environment like a Pop-up Coming up) then the playback will happen on the changed Settings.

User Can Specify a ThinkTime Multiplier as well. During Playback the User may decide that the interval needed to wait may be a multiple/fraction of the original WAIT Time and can alter that as per his convenience. This comes in handy if the Network/Hardware Configuration changes between Recording and Playback and may need differential delay during playback.

So Far alls well but what if during Recording User needed to take a break or his Manager dropped in for a quick chat :).. In such scenarios a ThinkTime of a large duration would have been recorded and would make the Playback Slower… However for such Scenarios User needs to modify the ThinkTimeUpperCutOFF to a high enough duration he will never think for and if the ThinkTime exceeds that duration it will be removed.

Usage Scenarios and Recommendation

ThinkTime is especially useful when a Client-Side Application is making a background thread Call (Web Service Call/DatabBase Service requests) and that results in the UI being updated. For such Scenarios the in-built Wait For Ready (WFR from now on) mechanism of RnP fails sometimes and the recommendation is to use ThinkTime in such scenarios. For Web Applications recommendation is to turn-Off ThinkTime as the built-IN WFR is good enough and ThinkTime adds extra delays making the Playback Slower.

Overlay Frames in WPF are sweet and present endless opportunity to innovate on the Application UI. I have seen some neat usage of it with great result. However there are some accessibility issues ( Wherein the ElementFromPoint returned is wrong )with Frame that renders Record and Play Unusable. However if the Frame is used in correct way then Record and Play will work just fine…

then there is a accessibility issue with the application. If we look at the UI Tree using UISpy and Hover over the Button Control we will see that the element we get at that point is the Frame and not the button. This is clearly wrong as if you send a click it will goto the button.

However things are not bleak and black and there is a easy workaround to get this working. If instead of the XAML structure mentioned above the structure is

Its been more than 3 years that i started this blog and really it died on me…i started stopped and then stayed stopped.. However with the product i been involved in on the final home run i think now i have lots to blog about.. Hopefully now that i have re-started this blog, it stays that way

All this while me and my teammates have been working on the next release of Visual Studio Team System and BETA2 of VSTS has already hit the web.. You can get more info from VSTS 2010 BETA2 Home. We have been working on developing an entire new set of Testing tools to power up the Test offering of VSTS. I have been working in particular on the Record and Play Engine that will power the Coded UI Test and the Fast Forward a Manual Test feature that comes with Microsoft Test and lab Manager.

Every week i plan to post at least 1 Blog detailing Record and Playback (RnP from now on )…Hopefully i will better that..

Well after seeing the run chase by South-Africa yesterday i am feeling really high. Not because they have ended Australia’s run of winning tournaments but because they have really shown that nothing is out of reach if u r willing …