Step 4: Writing GUI tests on multiple VM screens

Step Four: Writing GUI tests on multiple VM screens

Objective

This extra tutorial focuses on the minimum steps needed to develop a GUI test.

It is implemented by the tutorial_gui variant and test file.

Cartesian config

Similarly to the third tutorial, this extra tutorial makes use of at least two vms playing once again the roles of a (linux) server and a (windows) client:

- tutorial_gui:
    get_state_vm1 = linux_virtuser
    get_state_vm2 = windows_virtuser
    type = tutorial_step_gui
    vms = vm1 vm2
    roles = client server
    client = vm2
    server = vm1
    host_dhcp_service = yes

The variant definition is thus not that interesting and the focus remains on the test code.

Test script

Similarly to the extra dependencies for more elaborate remote methods, running a GUI test would require a virtual user to manipulate the screen on the virtual machine. Our choice of virtual user implementation is guibot and the main part of this sample GUI test looks like:

# click on a button on the server if available
bot = GuiBot(dc=server_screen)
bot.add_path(image_root)
if bot.exists('centos-kickstart-finish'):
    bot.click('centos-kickstart-finish')
else:
    bot.type_text('Anyone there?')

# click on a button on the client if available
bot.dc_backend = client_screen
if bot.exists('win10-start-button'):
    bot.click('win10-start-button')
else:
    bot.type_text('Anyone here?')

This code is pretty self-explanatory with the exception of the part where the bot changes screens from the server to the client and manipulates the GUI on different screens thanks to the VNC destkop control backend (here screen).

Of course, some minimal setup is required in order to reach this stage and it can be complicated enough to require additional setup nodes (tests) as reusable states which can be programmed into the linux_virtuser and windows_virtuser tests but here we simplify it thanks to the fact that we want to run the virtual user through VNC. So let's simply perform some minimal setup within the sample GUI test using a helpers module section with a corresponding run() setup like:

vmnet = env.get_vmnet()
vmnet.start_all_sessions()
vms = vmnet.get_vms()
server_vm = vms.server
client_vm = vms.client
vmnet.ping_all()

if not BOT_AVAILABLE:
    raise exceptions.TestSkipError("No virtual user backend found")
image_root = get_image_root()
set_logging(params.get("vu_logging_level", 20), test.logdir)
set_shared_configuration(params.get("smooth_mouse_motion", "no") == "yes")
server_screen = initiate_vm_screen(server_vm, 'vncdotool')
client_screen = initiate_vm_screen(client_vm, 'vncdotool')

The helper methods used in the calls above set some minimal logging and global configuration for the guibot backend that we leave to the reader (and the guibot documentation). One helper is still more relevant here however:

def get_image_root():
    try:
        from avocado.core.settings import settings
        testsuite_top_path = settings.get_value('i2n.common', 'suite_path', default="..")
        image_root = os.path.join(testsuite_top_path, "data", "visual")
    except ImportError:
        image_root = os.path.join("/tmp", "data", "visual")
    if not os.path.exists(image_root):
        raise IOError("No image root path was found")
    return image_root

This helper prepares the image root to be used by the virtual user when matching images on the screen. It uses the location to the test suite and in particular to the data folder where the "visual" data with all images required for this test can be found. Such "visual" folder could then be extended with subfolders with images for particular visual objects like some browsers (Firefox, Chrome), operating systems (CentOS 8, Windows 10), etc.