QA/Automation/Projects/Mozmill Shared Modules/API Refactor

Overview

Lead:	Geo Mealer
Co-workers:	Henrik Skupin
Dates:	Pilot Completion at end of Q1 2011
Status:	Exploring new ways to present the Shared API to simplify test scripts.
Repository Location:	http://hg.mozilla.org/users/gmealer_mozilla.com/mozmill-refactor/
Tracking Bug / Bug List:	bug 605343
Documentation:	TBD

Project details

We're exploring different ways to structure and present both Shared APIs and tests. Some values we're optimizing for are:

• Low learning ramp for writing Mozmill tests
• Understandable and verifiable test code
• Repeatable and accurate test runs

Initial ideas center around creating a custom "testing language" by splitting the Shared API into two classes of modules:

• API modules contain functions for completing complex tasks
• UI modules contain a map of the Firefox UI used for per-control access.

API modules would be primarily used in setup for tests where fine control isn't needed. UI modules would be used to simulate a QA Engineer running a test.

Some initial ideas for what we're targeting can be found in:

• Shared API Refactor -- Thoughts and Recommendations
• Code Sketches for Shared API Refactor

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. Controls in italics are unlikely to be fully developed in Q1 2011.

For more reference on these controls please see the [MDC XUL Control Reference].

1. Base classes to enable proxy binding
2. TextBox
3. Button
4. Description
5. Label
6. ToolbarButton
7. MenuList
8. Checkbox
9. Radio
10. ListBox
11. RichListBox
12. ProgressMeter
13. Tree
14. Menus
15. Image
16. Scale
17. Groupbox
18. Colorpicker
19. Datepicker
20. Timepicker

General Modules

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

1. Assertions
2. WaitFors
3. Services
4. Window Handlers (Match current functionality)
   • Modal
   • Non-Modal
   • Multiple Parallel
5. Localization (Match current functionality)
6. Preferences handling
7. Module Initialization Functions
8. Teardown helper functions
   • UI Reset
   • History Reset
   • Bookmarks Reset
9. Screenshots
10. Localization (Improve functionality)
11. 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.