Why do my Coded UI tests pause during playback?
If you’ve spent some time using VS 2010 Coded UI with Dynamics AX 2012 you’ve probably noticed that playback can be slow. Watching the playback, you will see that there will be some activity, then a pause, then some more activity, more pausing, a little more playback, more pausing, <sigh>. It makes you wonder.. what is it that the playback tool has to think so hard about that it has to pause?
It turns out the playback tool is not thinking. Instead, it’s looking around – looking around for the window that it needs to do its next operation on. It takes so long to find the window because of the uniqueness of Dynamics AX window titles and how Coded UI looks for windows.
When you do a recording with Coded UI, the recorder identifies certain search properties that are used to find the UI element on playback. For top level windows, the primary search property is the title of the window. Let me explain using an example.
Let’s say I’m recording a script to create a new sales order. The Sales Order form has a title that looks like the following:
After you complete the recording and generate code, go back and open the UIMap.uitest element in the Solution Explorer in VS. In the UI Control Map, right click on the top level node that represent this form (UISalesorder1ceuSalesoWindow was the name in my example). Select Properties in the pop-up menu. Then go to Search Properties in the Properties pane and click on the […] button. A screen shot of what I just described is shown below.
After you click on […], an Edit Search Properties form will come up. In it you will see one of the search properties is:
Name EqualsTo “Sales order (1 - ceu) - Sales order: SO-101375, Forest Wholesales”
If I play this back, it takes over 30 seconds. In fact, it takes about 25 seconds to do the first operation on the Sales Order form. Too slow!
But here’s the deal, if I look at the Sales Order form title, I see that it has a different title than the one that I recorded and that the Coded UI playback engine is looking for. The ID has incremented by one so that the title now is:
It’s surprising that the form is found at all given our Search Properties. It does find it because the playback engine’s Smart Match capability kicks in. What the engine is doing is first looking for a window with the exact match. It looks through all windows currently displayed. Then it waits. And looks some more. After all, it might take some time for the window to be displayed so the playback engine doesn’t want to be in a hurry. So it waits for a little while longer and then looks some more. Eventually, it gives up on finding a window that is an exact match. That’s when the Smart Match algorithm kicks and and it looks for windows with titles that are similar. Smart Match can pretty quickly figure out that this new window has a title that is almost the same as the other one and decides it’s the one to operate on. And off it goes.
So it’s cool that it works, but waiting for 20+ seconds for the exact match phase to timeout is tedious. Fortunately there’s a way around this. If you go back to the Search Properties window described above, you can change the properties. In this case. I’m going to change
Name EqualsTo “Sales order (1 - ceu) - Sales order: SO-101375, Forest Wholesales”
to
Name Contains “Sales order (1 - ceu) - Sales order: SO”
Now my playback was complete in around 8 seconds instead of over 30 seconds!
To summarize, minimize the pauses in your Coded UI playback with Dynamics AX 2012 by changing the window name search property from an EqualsTo statement to a Contains statement. This speeds up the playback engine’s search significantly, and speeds up your development and test execution process!