Overview

Excerpt

To ease the creation of Mozmill tests for a given subgroup, it's helpful to have a set of helper functions available, which can be called to achieve a wanted action. With the creation of shared modules we want to follow this idea and create function or even classes to simplify the access of single elements or whole dialogs.

Project details

Whenever you want to start to automate a new BFT/FFT subgroup on Litmus, you should first think about having a shared module in place. Creating a list of requirements should be the first step you will have to do as early as possible in the whole process. That will allow us to help you or even write the shared module on our own. Once it has been done, you can start writing Mozmill tests for that subgroup.

Identifying Requirements

This part is probably not trivial if you are doing it the first time. That's why we want to offer some help for the requirements definition process. By following the steps below you will be able to put a good list of items together.

Before you start with the list below, make sure that there hasn't been already made a request. Therefore check the BFT table of the Mozmill spreadsheet and also all open requests for shared modules. If your request cannot be found, you can start to identify the requirements.

1. Each of the tests will interact with a couple of ui elements. All those elements can be accessed in different ways. The easiest way is definitely its node id. But there are probably more elements which can't be reached by that method and requires a complex lookup expression. As a test writer you don't wanna be confronted with such a research task because it requires knowledge about the DOM and tools like the DOM inspector. Instead you want to simply use those elements and create sequential steps of actions. To be able to do that, the shared module has to give access to all elements in the same simple manner by only specifying the elements name and eventually an index. As result the getElement function has been added to all shared modules and has to be used to retrieve elements.

2. Tests from the same subgroup normally have similar actions which have to be performed to get into a given state. Those single steps shouldn't be performed again and again by the tests itself. Instead a function should be created in the shared module which combines those steps in a single call.

3. Sometimes the new shared module can have dependencies to other shared modules. Take the AddonsAPI as an example. It reads and writes some preferences and needs functions from the PrefsAPI.

Filing a Bug

To get the shared module implemented you will have to file a new bug. Use a clear summary and add the requirements you have compiled in the former chapter.

Implementation

The creation of shared modules is not as easy as creating tests, but it's more challenging because you really have to think in an abstract way. If you haven't written a shared module yet, please check our existing shared modules. Those can give you an insight how the code has to look like. You should also obey the test writing guidelines.

While creating the shared module you should immediately check if the functions you have added are working as expected. Therefore you can create a helper test module under firefox/helperClasses with the same name as the shared module itself. The shared module documentation explains how to include the shared module into a test.

Before the shared module can be checked-in a review is necessary. Therefore create a patch and ask for review. Details about that process can be found on MDC.