Changes to tab selection in 0.16

Jul 2, 2008 at 11:21 AM
In 0.16 you've addressed the issue described here http://www.codeplex.com/Thread/View.aspx?ProjectName=white&ThreadId=27589 

Using SelectTabPage on a tab UIItem or the Select method on a TabPage uses a mouse click to select the tab. This is not always going to work with all tab controls; tab controls can have pages that are not visible therefore the mouse click method wont click on the tab (such as in Visual Studio).

The way of selecting tabs before version 0.16 selected tab pages not currently visible. Could you add back in the original way to select tabs you had in versions earlier than 0.16 in addition to the changes in 0.16,  so we can have both ways to select a tab page?

Thanks,

James.
Coordinator
Jul 2, 2008 at 7:19 PM
This is indeed very good point and I understand it completely.
I have a question though, how would the user select a tab if it is not visible. In visual studio there is a button which can  be clicked to navigate(kind of scroll) to the tab.
The reason white tries to click instead of select because select doesn't do exactly what user does.
Jul 3, 2008 at 8:59 AM


viveksingh wrote:
This is indeed very good point and I understand it completely.
I have a question though, how would the user select a tab if it is not visible. In visual studio there is a button which can  be clicked to navigate(kind of scroll) to the tab.
The reason white tries to click instead of select because select doesn't do exactly what user does.



Taking Visual Studio as the example, as well as the button you mention, there is also a drop down menu to the right of the tab control that allows the user to select tab pages (both visible and not visible). The problem with using either the button or the drop down menu it that White does not 'see it' so I can't automate it reliably.

I'd question the argument that changing the tab selection as you have, simply because clicking on the tab is also not only what a user would do, the user could also select the tab using the keyboard (as one example). The change made makes the automation of tabs more user like only in a single specific case, in the case where the user clicks on a tab to select it.

Do you think that future versions of White will have less methods to automate controls that use Microsoft UIA, as automating controls in this way doesn't represent 'user like' interaction. If this is the case then why would someone use White over using basic Win32 libraries directly to control the mouse/keyboard? In my experience using mouse/keyboard directly in test automation is much less reliable than using UIA and a switch to a more  mouse/keyboard slanted framework would impact heavily on test reliability.

I'd also like you to consider the argument that its not always necessary for the actions in an automated test to model what a user would do, take the following example. I have test with a goal and to achieve that goal it needs to manipulate a tab control, the tab control isn't the test goal so I want to manipulate the tab control in the quickest and most reliable way so that I can get to my test goal.  I have other tests, both manual and automated, that cover tab controls, so I know I don't need my current test to interact with the tab control in anything other than then quickest and most reliable way. In this case interacting with the tab control by a mouse click puts an unnecessary element of risk in my test, I'd much rather, in this case, use UIA to automate the tab control directly.

I hope this all makes sense,

Thanks,

James.

Coordinator
Jul 4, 2008 at 7:31 PM
One of the idea of white has been to take away the mouse clicks and keyboard strokes from the test. Sometimes by abstracting them (button.Click) and sometimes by assuming it (comboBox.Select which scroll automatically to select the item).
While this is not a philosophical debate for me (maybe because I don't really write functional tests full time) but I always ask this question, "how user would do it?". If it is possible then do it that way. This doesn't mean you need to use keyboard and mouse in your tests do this. You can use abstractions.
I totally buy your argument that keyboard and mouse stuff are not very reliable (still). At some point I want to have two modes, real user like and non-intrusive mode in white. Its a shame that UIAutomation is not reliable enough (sometimes crashes) when it relies on UIAutomation pattern approach for performing operations. Also client side providers based things use windows api anyway.

Coming back to your original problem of tab select, you made a valid argument with good example (I was an idiot to not see that UIA doesn't identify the button). This would make in next release of white, hopefully UIAutomation would play along.