Auto-tools/Projects/Mozmill/Mozmill 2.0

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

These are some preliminary thoughts for Mozmill 2.0. Feel free to add your ideas below. Feel free to add your ideas to the "whiteboard" section, and in the meetings and on the dev-list we'll discuss whether they belong in the "Must Have" or "Nice to Have" category.

The Whiteboard -- Add Something!

• (Maybe) Native event system for event generation - (onplan)
• Simpler syntax for performing element identification in chrome content (onplan)
• Common JS code loading modules (onplan)
• Make the recorder record usable tests, remove some of its flakiness (onplan)

Must Haves

• New UI for extension based on Bespin (done)
• Refactored and shared command line handling (with the rest of the test harnesses) (onplan)
• Refactored and shared process management for process under test (shared with other test harnesses) (onplan)
• Better support for test debugging

The Plan

As things bubble down into a plan, they will end up here. We will remove items above as they are landed on the plan.

Module Loading System

• Replace Module loading system with CommonJS loading for both tests and mozmill modules as well
  • reuse assert module from node to replace the JUM module entirely (possible)

Command Line

https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr&query_format=advanced&status_whiteboard=mozmill-2.0%3F%20CLI&resolution=---&resolution=DUPLICATE

• Refactor inheritance model to make it simpler to extend
• Better slots for commands to make it less confusing
• Better option handling
• Use same options as other test harnesses where possible (work toward shared option class)

Event System

• Expected Events - see bug 583604
• Native Events are needed as well to remedy focus issues (take Selenium code)
  • Windows - should be working
  • Linux - need mouse support
  • Mac - unknown
  • Integration issues with these binary components now being a part of mozmill
  • Provide a fallback mechanism to eventutils

Network Handling

• Use ctypes for Javascript side of JSbridge so that if the application goes into offline mode our socket isn't hosed. (ctypes to necko libraries directly)
• Make a restart functionality that saves current state of controller - better restart tests.

Test Harness for Mozmill

• Use the Jetpack test harness to make a test harness for the mozmill system itself
• Clean out the tests/ directory and ensure all the cruft is eliminated from there (already done?)

Httpd.js

• Should be removed from mozmill tree
• Use existing server available from test package.
• Need manifest support to denote what tests require httpd, and will likely need the same sjs support that we will need to do remote httpd tests for reftest and xpcshell

Manifest support

https://bugzilla.mozilla.org/show_bug.cgi?id=585106

• Manifest should help designate what is and is not a test file
• Manifest should provide canonical names for tests: bug 580057
• Manifest should indicate what test is restart, which is not, and can tie together restart tests so they don't have to be named test1, test2, etc : bug 585112
• Use same manifest as universal manifest (including parsing code).

Mozmill Python Side Refactor

• Break up Mozmill into separate python files in one package: https://bugzilla.mozilla.org/show_bug.cgi?id=568998
  • mozmill.py
  • restart.py
  • logging.py
• __init__.py can contain convenience imports (or not!)
• each CLI program should have its own script (do we need more than one CLI program? Or is mozmill --app=thunderbird sufficient if whether tests are restart are contained in the manifest)

Mozrunner Refactor

• Break into reusable components based on functionality
• TODO: How does someone install "mozrunner" if it is a collection of packages?

Observer/Listener System

• Get rid of sleeps entirely
• Waits all become "waitForNotification" types of paradigms
• Might be able to reuse some jetpack api's for this...
• Need to be able to observe both application and mozmill level events

E10S

• Support event generation refactoring will help us support e10s changes
• Might be issues that will need to be addressed in the inspector and recorder

Inspector

• Overlay into the Firefox 4 Inspector (if available in the application) to have it do inspecting for us
• Inspector should prevent default click behavior to make it easier to use (go back to using key control?)

Recorder

• User should be able to record a test and play it back without changing the tests
  • Will need to use sleeps when recording to pause the test between actions to simulate the user's time spent between actions.

ElementsLib

• Make elements easier to lookup by providing a editor completion (or at least a reasonable dot notation) for elements in chrome of each application. So you can say toolbar.uribar.textbox instead of the giant Lookup expression. This is a mapping that should be generated for chrome elements. We should be able to generate a mapping for all non-dynamic chrome elements to their necessary expressions.