Project Plan

Goal

Our goal by end of Q1 2011 is to complete a pilot of the new shared module libraries within the Mozmill team.

Assuming no major problems unearthed during the pilot, we will be able to move forward with migration and further community rampup during Q2.

Use Case Scope

At the end of Q1 2011, the refactored shared module library should be sufficient to cleanly and efficiently implement tests involving the following elements:

The entire main Firefox window, especially:

Tabbed browsing

Location Bar

Bookmarks Bar

Multiple browser windows/non-modal dialogs in parallel

Modal dialogs, such as Preferences

Test and synchronization statements such as:

Fatal assertions

WaitFors

Module Scope

From a modular point of view, the shared modules can be roughly broken down into the UI Map and General Modules.

The UI Map includes proxy objects for individual XUL controls, so that a hierarchical representation of the UI layout can be created. This map will largely replace direct access of the Mozmill controller for UI operations.

General Modules are those that provide higher level utility services, test control statements, or wrap Mozilla Platform back end services.

UI Map

The UI Map is expected to cover the following scope, in priority order. While basic classes will be established for all controls, controls in italics are unlikely to be fully developed in Q1 2011.

General Modules

The General Modules are expected to cover the following scope in priority order. Modules in italics are unlikely to be developed in Q1 2011.

Assertions

WaitFors

Services

Window Handlers (Match current functionality)

Modal

Non-Modal

Multiple Parallel

Localization (Match current functionality)

Module Initialization Functions

Teardown helper functions

UI Reset

History Reset

Bookmarks Reset

Preferences handling

Screenshots

Localization (Improve functionality)

Window Handlers (Improve functionality)

Modal

Non-Modal

Multiple Parallel

Additional Firefox-specific helper functions will also be created as we encounter the need while migrating tests.

Development Flow

This project is loosely structured as an Agile project, starting with one week sprints.

Because of the distributed nature of the development team and the differing development concerns, UI Map development and General Module development will follow somewhat different flows within their sprints, as detailed below.

Milestones have been defined. When each milestone is reached, shared module structure will be reviewed for acceptance and possibly refactored to pay back any development debt incurred during the sprints.

Completion for any library module means done to the point of accomodating current common test scenarios, with sufficient structure and patterns established to add new scenarios as they occur.

Completion also includes creation of documentation and unit tests exercising each module.

UI Map

At the beginning of each sprint, a number of existing Mozmill tests will be chosen, concentrating on those that rely on the highest priority control remaining on the queue above.

These tests will be ported to the library, adding functionality to the UI Map as needed by the tests.

General Modules

At the beginning of each sprint, one or more modules will be chosen from the queue above.

The current Mozmill code will be surveyed to come up with an individual scope for that module (e.g., which assertions are currently used, what teardown functionality is needed).

The module will be developed to that level of functionality.

It is likely these modules will also be expanded as needed by the test porting detailed above.

Milestones

Milestones are provided both to meter progress and to synchronize development between the two tracks. All portions of any given milestone should be reached prior to moving on to the next milestone.