WPF- Handle EventAggregator Events, and reading metadata

Class library usage, coding and language questions.
Tilak
Posts: 3
Joined: Mon Feb 24, 2014 9:18 pm

WPF- Handle EventAggregator Events, and reading metadata

Post by Tilak » Wed Apr 09, 2014 12:44 pm

We are using Ranorex for WPF UI Testing. WPF application internally makes use of EventAggregator messages and heavily doing asynchronous updates.

Currently our ranorex test cases are failing for Invalid use cases because the test cases expect synchronous behavior. (Example, We are waiting for data update on a Screen, but we do not reliably know when, or We clicked a button, and many a time this click does not get activated (occurs 2-3 % of times)).

Our UI Team has suggested to listen to EventAggregator events that they send whenever any UI Action is invoked.

Q1. What is the best practice to listen to WPF events, and Event Aggregator events using Ranorex
Q2. Is it possible to recognize some data/metadata through Ranorex API, which is not visible on screen. (If this is possible, UI team will add some metadata to UI controls, and they will expect us to read those)


Thanks

mzperix
Posts: 137
Joined: Fri Apr 06, 2012 12:19 pm

Re: WPF- Handle EventAggregator Events, and reading metadata

Post by mzperix » Thu Apr 10, 2014 10:55 am

Hi Tilak,

I have a remark regarding Q2:

Ranorex can identify not visible objects, and it can get any property value. Just make sure that you do not want to do actions that requires to be seen on screnn, like mouse or keyboard actions.

You can check this, by looking at SPY. The elements that's text is grey are not visible on scree, while those that are black can be seen.

Try to get an element that is not visible all the time, then put it in repository, then make a get value action on it.

Hope this helps,

Best Regards,
Zoltán Major

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 7470
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: WPF- Handle EventAggregator Events, and reading metadata

Post by odklizec » Thu Apr 10, 2014 12:23 pm

Hi,

Is there an element in GUI, which indicates the update is in progress? Or something that would visually indicate the update is finished? If so, you could use Wait For Exists or Wait For Not Exists which "pauses" the execution until an element is not available or still available in GUI.
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

Tilak
Posts: 3
Joined: Mon Feb 24, 2014 9:18 pm

Re: WPF- Handle EventAggregator Events, and reading metadata

Post by Tilak » Fri Apr 11, 2014 10:44 am

There are visual indication, but not good enough, as there are continuous data updates, and we have to listen to specific ones (and ignore remaining ones).
Which updates to pick can be identified easily if we hook up to the application and listen to their events. This is the reason, We are looking for best way to listen to events/application notifications.

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 7470
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: WPF- Handle EventAggregator Events, and reading metadata

Post by odklizec » Fri Apr 11, 2014 12:23 pm

Is there an API in your AUT that you would allow you to connect to that app from another app? I'm not an expert, but I think the best way for you would be to somehow connect to the app from Ranorex (using C#/VB.Net code) and then "listen" to the events/notifications you expects?

I can imagine a user code, that would start the update process, then hook-up to your app, and then using do..while (or similar) loop wait for the appropriate event. When the event arrives, you could jump out from the loop and continue with the rest of test. But maybe there is a better way to achieve what you want? ;)
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration