Dynamics 365 - Test Automation Experience

So, as we have been developing Rapise, the ultimate UI test automation tool, we decided to focus not just on generic support for any web application but also build libraries to enhance the test automation experience for specific applications. For example, the Microsoft Dynamics 365 family of products includes several very different solutions:

• Dynamics 365 for Sales (successor of Dynamics CRM)
• Dynamics 365 for Operations (brand new web application based on the client/server Dynamics AX)
• Dynamics 365 Business Central (successor of Dynamics NAV Web Client)

Each listed test automation target is rather unique and brings certain challenges to test automation.

Let's look at what the difficulties are. Many of them are related to the automatic recording of reliable XPath locators for DOM elements

Element ID

Life is easy when elements have static IDs which have the same values every time you visit a page. But this is not the case with Dynamics 365.

Dynamics 365 Business Central uses dynamic IDs, guid style:

<div id="CDF2B" class="ms-nav-group no-caption">
    ...
</div>

Dynamics 365 for Operations uses semi dynamic IDs, the number in the middle may change:

<button class="appBarTab-header allowFlyoutClickPropagation" type="button" id="CustFreeInvoice_3_AccountingActionsTab_button" aria-expanded="false">
    ...
</button>

Dynamics 365 for Sales uses semi dynamic IDs ending with generated numbers:

<div id="appGridQueryFilterContainer_Component8738712"  style="height: 76px">
    ...
</div>

Dynamic IDs are not reliable at all and semi dynamics IDs require special processing to ignore the changing part.

Window Title

Rapise groups recorded objects into Windows. The window for a web application is determined by the title of a browser at the time of object capturing. Here is a title example from (B):

New - Sales Order - S-ORD101018 ∙ School of Fine Art - Dynamics 365 Business Central

If it always records the title without any changes then after several recording sessions we'll end up with a mess - lots of similar windows with a couple of objects inside:

New - Sales Order - S-ORD101016 ∙ Trey Research - Dynamics 365 Business Central
New - Sales Order - S-ORD101017 ∙ School of Fine Art - Dynamics 365 Business Central
New - Sales Order - S-ORD101018 ∙ School of Fine Art - Dynamics 365 Business Central

This is why Rapise replaces the dynamic window titles with static equivalents:

New - Sales Order - Dynamics 365 Business Central

Layers

Dynamics 365 Business Central is built with layers. A page may contain DOM elements for several views. All are hidden except the one with highest z-order.

<div class="spa-container">
    <div class="spa-overlay" tabindex="-1" style="display: block; z-index: 5;">
        ...
    </div>
    <div class="spa-view" style="z-index: 1;" >
        ...
    </div>
    <div class="spa-view" style="z-index: 2;" >
        ...
        <a class='icon-Home'> ... </a>
    </div>
    <div class="spa-view" style="z-index: 3;" >
        ...
        <a class='icon-Home'> ... </a>
    </div>

It leads to the fact that the same element may be found several times if the XPath does not take into account the layered structure:

    //a[@class='icon-Home']

or the element will not be found if the XPath is too straightforward (just enumerates nodes with attribute values):

    //div[@class='spa-view' and @style='z-index: 1;']  ...  /a[@class='icon-Home']

The problem originates from the fact that when you first login to the application it contains just one layer, after navigating through forms the number of layers grows.

Rapise handles layers for (B) automatically and generates XPath that always works with top most layer.

Attributes

Each web technology has it's own style of using attributes. It is an interesting task to determine which attributes can improve the resiliency of an XPath expression. Here are some statistics we gathered for Dynamics 365 applications. The higher an attribute bar the greater it's impact on element identification within a given application. Attributes with zero influence on element recognition ability are omitted in the graphs. The ID attribute is excluded as well.

Dynamics 365 for Sales

Dynamics 365 for Operations

Dynamics 365 Business Central

Rapise uses a specific set of attributes for each of the Dynamics 365 solutions to improve resiliency.

Grids

Any business application strongly depends on grids: tables with orders, customer lists, product lists, etc. And every grid in a particular web app has a unique internal structure. Rapise does an excellent job on handling grids in Dynamics 365. It recognizes cell clicks and captures the recording of high level user actions instead of the lower level DOM elements. Here is a fragment of recorded and parameterized Dynamics 365 Business Central test:

But Can Rapise Test Anything Except Dynamics 365?

The short answer is Yes, of Course! If your application is approaching Dynamics 365 in terms of level of complexity, you can go down the road we paved with techniques and methods developed for Dynamics 365. If you have a simpler application or are able to influence its development to make it more automation friendly you'll get the experience we observed when testing our own test management product SpiraTest.

In SpiraTest all the important elements have IDs, there are no hidden layers, no dynamic IDs. So Rapise is able to record reliable tests on SpiraTest without any effort, and without any special libraries.

What's Next?

If you are looking to test a Dynamics 365 solution please contact us at sales@inflectra.com and we'll schedule a demo for you. If you plan to perform end-to-end testing of your own complex modern or legacy application - certainly contact us, we love challenges and have all the tools to beat the competition.