Building Testable Components for ATF

#Madrid Release , #Automated Test Framework , #Testable Components

Dave Slusher

4 minute read

During our flurry of posts about Madrid features, I posted about some of the changes to Automated Test Framework . There were a few pieces that I didn’t mention so I am going to round that out over time, starting with testable components. Speaking personally, ATF is one of my favorite new development tools of the last three years. What can I say, I love having robots working for me. There is a reason I own this guy.

Eufy Robovac 30C

Testable Components

A Madrid feature that expands the range of coverage is that of testable components. I previously covered the page inspector that given a UI page or Service Portal page will examine the page to determine available components with properties and operations. As the developer, you actually can control that and even add additional logic to that testing.

By adding the attribute sn-atf-class to an HTML object, you can specify the name of a JavasScript object that will provide the testable interface. As of Madrid, you have the ability to mark a component as a settable or clickable, with an interface available for each. This may be hard to visualize, so here is what that would look like:

<div sn-atf-class="ClickableTestComponent">
    <label for="a_clickable_checkbox">Am I Clicked?</label>
    <input type="checkbox" id="a_clickable_checkbox" checked="true"/>
</div>

The classname specified must resolve to a JavaScript object, typically defined in script inline. The interface it must implement are these functions:

initialize($super, element, area);
click();
getValue();
isDisabled();

Note that the return value is a JSON object with two fields, “success” and “result”. Don’t be confused by the example because all the results are boolean in this case. Success being true means the testable action worked, which is different than the value returned.

<script>
var ClickableTestComponent = {

    initialize: function($super, element, area) {
        $super(element, area);
        // any additional setup steps go here
    },

    click: function() {
        document.getElementById('a_clickable_checkbox').click();
        return {success: true};
    },

    getValue: function() {
        var isChecked = document.getElementById('a_clickable_checkbox').checked ? "true" : "false";
        return {success: true, result: isChecked};
    },

    isDisabled: function() {
        if (document.getElementById('a_clickable_checkbox').disabled)
            return {success: true, result: true};

        return {success: true, result: false};
    },

};
</script>

If the component being developed is instead one that takes a value, then it would be a “settable” component rather than “clickable.”

    <div sn-atf-class="SettableTestComponent">
        <label for="a_reference_field">Related Incident</label>
        <input type="text" id="a_reference_field" name="incident"/>
    </div>

This looks very much like the previous example with a few additions. The attribute “isSettable” must be true, and we have replaced the click() function with setValue(value)

<script>
var SettableTestComponent = {

    isSettable: true,

    initialize: function($super, element, area) {
        $super(element, area);
    },

    // The value parameter is a string
    setValue: function(inputString) {
        document.getElementById('a_reference_field').value = inputString;
        return {success: true};
    },


    getValue: function() {
        var value = document.getElementById('a_reference_field').value;
        return {success: true, result: value};
    },

    isDisabled: function() {
        if (document.getElementById('a_reference_field').disabled)
            return {success: true, result: true};

        return {success: true, result: false};
    },
};
</script>

Note that in this example, there is a wrinkle. The textfield that comprises this component is a reference field. We can handle that too! By using the sn-atf-data-type you can specify some data types for the field that isn’t just a straight string. Passing to sn-atf-data-type-params a JSON object that defines “reference” and “reference_qualifier” fields provides to ATF enough information to know how to populate the field. Let’s look at our example above but specifying that this field is a reference to the Incident table that only looks at active records.

    <div sn-atf-class="SettableTestComponent">
        <label for="a_reference_field">Related Incident</label>
        <input type="text" id="a_reference_field" name="incident"
        sn-atf-data-type="reference" sn-atf-data-type-params='{"reference":"incident","reference_qual":"active=true"}'/>
    </div>

These are simple examples but demonstrate that you can have an arbitrarily complex object on a page that may be doing complicated client-side work. By adding in a little bit of code you can give ATF clues on how to handle it that may not be easily introspected otherwise.

I am curious to hear if any developers or QA teams have worked with this yet. ATF tends to be a bit of a lagging indicator because it takes time for the release to get out and teams to get comfortable with the new features and incorporate them in their day to day work. Let me know in comments if you have tried and what the result was. Let’s get testy!

Comments