Home · All Namespaces · All Classes · Grouped Classes · Modules · Functions

[Previous: Chapter 3] [Contents]

Chapter 4: Putting It All Together

Using the simple building blocks of textual input and output and navigation functions, with the data driven testing approach, a full testcase can be written for creating a new contact. Note that the functions for creating and verifying a contact have been moved out into helper functions; this allows them to be reused for subsequent tests. This is very useful for cases where, for instance, one test's precondition might be that a contact has been successfully created.

    testcase = {
        initTestCase: function() {
            // Start "Contacts" when the testcase starts.
            startApplication( "Contacts" );
        },

        creating_a_contact: function(name, emails, company, jobTitle, businessPhone) {
            create_contact(name, emails, company, jobTitle, businessPhone);
            verify_contact(name, emails, company, jobTitle, businessPhone);
        },

        creating_a_contact_data: {
            simple:           [ "Billy Jones",      "billy@example.com",   "Hotdog Inc.",     "Hotdog Engineer",    "12345"   ],
            letters_in_phone: [ "Joan Example",     "joan@example.com",    "Example Inc.",    "Exemplary Engineer", "555 EXA" ],
            three_names:      [ "Jon John Johnson", "jjj@example.com",     "Sillynames Inc.", "Dog Walker",         "12345"   ],
            no_job:           [ "William Doe",      "bill@example.net",     undefined,         undefined,            undefined ]
        }
    }

    // Create a contact with the given details.
    function create_contact(name, emails, company, jobTitle, businessPhone) {
        // Verify that we're on the home screen of the "Contacts" app.
        waitForTitle( "Contacts" );

        // Select "New contact" from context menu.
        select( "New contact", optionsMenu() );

        // Navigate to the "Contact" tab.
        // This is the default tab, but with this code we ensure the
        // test will work if it becomes no longer the default.
        select( "Contact", tabBar() );

        // Fill in fields on the "Contact" tab.
        // enter() returns immediately if we try to enter an undefined
        // value.
        enter( name,   "Name" );
        enter( emails, "Emails" );

        // Navigate to the "Business" tab.
        select( "Business", tabBar() );

        // Fill in fields on the "Business" tab.
        enter( company,       "Company" );
        enter( jobTitle,      "Title" );
        enter( businessPhone, "Phone" );

        // Press the Back key to commit the new contact
        select( "Back", softMenu() );
    }

    // Verify that a contact with the given details exists.
    function verify_contact(name, emails, company, jobTitle, businessPhone) {
        // Verify that we're on the contacts list.
        waitForTitle( "Contacts" );

        // Select the contact with the given name.
        select( name );

        // Navigate to the "Details" tab and get the displayed text.
        select( "Details", tabBar() );
        var details = getText();

        // Now verify that the details contains all of the non-null information
        // for the contact.
        if (name != undefined)          verify( details.contains(name) );
        if (emails != undefined)        verify( details.contains(emails) );
        if (company != undefined)       verify( details.contains(company) );
        if (jobTitle != undefined)      verify( details.contains(jobTitle) );
        if (businessPhone != undefined) verify( details.contains(businessPhone) );
    }

The above test has been written to be reasonably permissive; it will succeed as long as the text shown by the contacts application contains all of the information for the created contact, and it does not test things such as the formatting of the given text, and does not test every single field. However, this test is well insulated against minor changes to the tested application GUI.

QtUiTest allows the tester to decide how strict a test should be. If pixel-perfect accuracy is required for output, a test can be written to test every screen with verifyImage(). In contrast, a high-level text-based approach as shown above can result in effective tests which remain correct even when significant UI changes occur.

There are many other methods available for use; for further information, refer to the QSystemTest documentation.

[Previous: Chapter 3] [Contents]