Hi all,
I'm looking for advice on a coded step.
We have a WPF application which uses System.Windows.Controls.ListView as well as Telerik controls. I have a ListView with a specific name and I'd like to locate and cast it from the running app, so that I can then iterate through the ListItems within it.
I had assumed that I could use something similar to:
public void Survey_Control_Readonly_Switcher_CodedStep()
{
WpfApplication app = Manager.ActiveApplication;
Assert.IsNotNull(app);
System.Windows.Controls.ListView list = app.MainWindow.Find.ByName<System.Windows.Controls.ListView>("DisplayFieldItems");
Assert.IsNotNull(list);
foreach <etc....>
}
But this does not seem to work, where it does if I use it with (e.g.):
Telerik.WebAii.Controls.Xaml.Wpf.RadGridView grid = app.MainWindow.Find.ByName<Telerik.WebAii.Controls.Xaml.Wpf.RadGridView>("ScriptGrid");
Does anyone have any pointers? I've gone through the code examples but not found anything relevant. I do have the correct assemblies loaded and called.
4 Answers, 1 is accepted
Hello Lawrence,
Test Studio comes with built-in wrappers for the Framework to automate the WPF controls including the system ones. The ListView and plenty of others wrappers are part of the ArtOfTest.WebAii.Controls.Xaml.Wpf namespace - see API ref docs for ListView class here.
You will need to use anything similar to the line below:
ArtOfTest.WebAii.Controls.Xaml.Wpf.ListView list = app.MainWindow.Find.ByName<ArtOfTest.WebAii.Controls.Xaml.Wpf.ListView>("DisplayFieldItems");
I hope this helps.
Regards,
Elena
Progress Telerik
Thanks very much Elena that was very helpful. I've now managed to grab the correct list element in my code.
As an aside (I can open a new question if you'd prefer): When using while...loops in (non-coded) test steps, is there any way to specify a timeout? Number of iterations, execution time, etc?
I use quite a few element verification (exists/enabled/visible/etc) while...loops to click a WPF button again if the required element has not appeared, but in certain cases these can get stuck in an infinite loop.
Hi Lawrence,
I wouldn't use the while..loops for such kind of scenario. Instead you can adjust the wait/verify steps to wait longer, or, if needed, add different state of the app to be expected.
Each separate step can be set to use different than the default timeouts in its properties. You can see details at the bottom of the pane for each property when you select it in the pane.
You can test some scenarios with these and let me know if they suit your needs. In case there's any scenario that still can't be handled as expected we can discuss its specifics further.
Regards,
Elena
Progress Telerik
Hi Elena,
Thanks for your reply, but the wait/verify step properties don't appear to handle the scenario I fairly regularly see in my WPF app testing.
Sometimes, a 'click' step does not actually properly 'click' on a button element. My observation is that on occasion the click just has the effect of hovering over/selecting the button (i.e. a tooltip will pop-up for the button, but the button is not actually 'clicked'). This may be due to other processes hogging compute power, focus being pulled from the main application window by an automated task, etc.
So, to mitigate the above, I have needed to introduce a large number of while...loops in my tests, which effectively do the following:
1. Verify button element exists.
2. Mouse left click on button element.
3. While...loop:
a. While <verify new element which only appears when step 2 is successful is NOT in DOM>.
b. Click step 2 button again.
The verify/wait steps that you detail above do not appear to have properties which can cover the same behaviour as my while...loop verifications; they will just fail after the element wait timeout.
Please let me know if I've misunderstood.
Hi Lawrence,
Thanks for adding these notes. From my perspective you need to focus on steps 1. and 2. in this sample scenario and align these with the state of the application so that the click happens for each test run.
During the test run all actions are performed much faster that a real used would do while recording the scenario, for example. Therefore the test then needs to be adjusted to fit the speed of the application responsiveness. For this particular example it seems that using a single 'Verify element exists' verification is not sufficient - I guess that there are other actions before that and even if the element is already in the DOM, there are still ongoing changes in the window and the button cannot yet accept the click.
Depending on the actual state of the application, you can choose to add another type of verification for that same button element, or use another element from the window which appears at last and the app is then ready to process the next action.
If you want to continue this discussion I will suggest to submit a private support thread where you can share the test failure details and we can investigate the specific occurrence.
Thanks for your cooperation.
Regards,
Elena
Thanks Elena - I will move this to a private support thread when I'm back from holiday. The WPF app in question is very complicated, has many buttons, grids and other elements on each page so, while I can see the logic in creating a test step to wait for the last element on page to load, I'm not sure how I'd work out which element that is in each case.
I'll pick this up with you on my return.