Auto-tools/Projects/Loderunner - Revision history

Jhammel: /* Identify the set of components to generalize */ add talos to this list

2010-05-25T16:09:34Z

Identify the set of components to generalize: add talos to this list

← Older revision		Revision as of 16:09, 25 May 2010
Line 144:		Line 144:
	** handles processes ''(TODO: list functionality)''		** handles processes ''(TODO: list functionality)''
	** running firefox		** running firefox

			* talos
			** deals with profiles (though tightly coupled with running tests)

Jhammel: note need for Log Parser

2010-05-24T22:18:47Z

note need for Log Parser

← Older revision		Revision as of 22:18, 24 May 2010
Line 51:		Line 51:
	* Extension Point - provide both in test logging as well as debug logging for testing during development.		* Extension Point - provide both in test logging as well as debug logging for testing during development.
	* Extension Point - should be able to reuse this logging functionality in new programs without bringing along unreleated pieces (should be stand alone)		* Extension Point - should be able to reuse this logging functionality in new programs without bringing along unreleated pieces (should be stand alone)

			See also the Log Parsing section.

	= Dependency Management =		= Dependency Management =
Line 77:		Line 79:
	* Handles reading configuration variables from a file		* Handles reading configuration variables from a file
	* Makes the config variables available for use by other components		* Makes the config variables available for use by other components

			= Log Parser (potentially) =

			While this might be worth tackling separately, as none of the harnesses use this, parsing failures from the logs is also related. Having a unified log format will make this much easier. Current ''topfails'' as well as ''brasstacks'' (and probably more) have this duplicate functionality. The parser should really ship with the writer once it is a free-standing component.

	= API Discussion =		= API Discussion =

Jhammel: add section for components to generalize

2010-05-24T18:29:32Z

add section for components to generalize

← Older revision		Revision as of 18:29, 24 May 2010
Line 123:		Line 123:
	# Integrate said modules into the existing harnesses, refactoring specialized data as needed (and moving basic functionality into these components where appropriate)		# Integrate said modules into the existing harnesses, refactoring specialized data as needed (and moving basic functionality into these components where appropriate)
	# Profit!		# Profit!

			= Identify the set of components to generalize =

			* mozrunner
			** deals with profiles
			*** creates new (temporary) profiles
			*** installs addons
			*** sets preferences
			** manages processes
			** runs applications

			* automation.py: http://mxr.mozilla.org/mozilla-central/source/build/automation.py.in
			** deals with profiles ''(TODO: list functionality)''
			** handles processes ''(TODO: list functionality)''
			** running firefox

Jhammel: move process management before application management, since the latter should consume the former

2010-05-24T18:22:55Z

move process management before application management, since the latter should consume the former

← Older revision		Revision as of 18:22, 24 May 2010
Line 18:		Line 18:
	** Able to specify a set of "sessionrestore" data for the profile		** Able to specify a set of "sessionrestore" data for the profile
	* Extension point - allow people to easily create their own profiles with their own unique data		* Extension point - allow people to easily create their own profiles with their own unique data

			= Process Management =
			* Obtain running processes
			* Kill running processes
			* Start a process in a monitorable and killable way

	= Application Management =		= Application Management =
Line 72:		Line 77:
	* Handles reading configuration variables from a file		* Handles reading configuration variables from a file
	* Makes the config variables available for use by other components		* Makes the config variables available for use by other components

	~~= Process Manager =~~
	* Obtain running processes
	* Kill running processes
	* Start a process in a monitorable and killable way

	= API Discussion =		= API Discussion =

Jhammel: section noting recommendation for process handling

2010-05-24T18:21:33Z

section noting recommendation for process handling

← Older revision		Revision as of 18:21, 24 May 2010
Line 72:		Line 72:
	* Handles reading configuration variables from a file		* Handles reading configuration variables from a file
	* Makes the config variables available for use by other components		* Makes the config variables available for use by other components

			= Process Manager =
			* Obtain running processes
			* Kill running processes
			* Start a process in a monitorable and killable way

	= API Discussion =		= API Discussion =

Jhammel: /* API Discussion */ recommend alternate form for preferences

2010-05-24T17:34:14Z

API Discussion: recommend alternate form for preferences

← Older revision		Revision as of 17:34, 24 May 2010
Line 91:		Line 91:
	myApplication = ApplicationManager(profile, myCmdLineMgr.getAllOptions(), mylogger)		myApplication = ApplicationManager(profile, myCmdLineMgr.getAllOptions(), mylogger)
	myApplication.start()		myApplication.start()
			</pre>

			''Why a list of dictionaries for prefs instead of just a dictionary, e.g:''
			<pre>
			myPrefs = { "user.pref.foo": "5" }
			...
			profile.writePref(**{'some.new.pref': 'some.new.value'})
	</pre>		</pre>

Jhammel: spelling correction

2010-05-24T16:50:57Z

spelling correction

← Older revision		Revision as of 16:50, 24 May 2010
Line 1:		Line 1:
	We have a ton of duplicated code in our test harness infrastructure. We have several components that ought to be easy to reuse and aren't. Some that were created to be easy to reuse and still aren't. We need a better set of APIs for doing low-level harness tasks that all our code can reuse and share and that shared code should provide an API that is useful and simple to use so that other people (and us) can build on top of it without reinventing the wheel or further duplicating then tailoring the existing code. This project aims to provide this low level API.		We have a ton of duplicated code in our test harness infrastructure. We have several components that ought to be easy to reuse and aren't. Some that were created to be easy to reuse and still aren't. We need a better set of APIs for doing low-level harness tasks that all our code can reuse and share and that shared code should provide an API that is useful and simple to use so that other people (and us) can build on top of it without reinventing the wheel or further duplicating then tailoring the existing code. This project aims to provide this low level API.

	Let's start a discussion on the API and so in that ~~vien~~, let's list out the requirements.		Let's start a discussion on the API and so in that vein, let's list out the requirements.

	= Some Requirements =		= Some Requirements =

Jgriffin at 21:47, 19 May 2010

2010-05-19T21:47:07Z

← Older revision		Revision as of 21:47, 19 May 2010
Line 61:		Line 61:
	* Handles validation of command lines (which can be overrided by the harness)		* Handles validation of command lines (which can be overrided by the harness)
	* Extensibilty point - test harnesses will need to be able to add their own specific command line options		* Extensibilty point - test harnesses will need to be able to add their own specific command line options

			= Test List Generator =
			* Purpose: builds a lists of tests to run
			* Handles reading and parsing a manifest file
			* Optionally accepts a list of criteria to use for including/excluding tests (e.g., "maemo", "android")
			* Extension point - derive the test list from other sources, e.g., a database

	= Config File Manager (potentially) =		= Config File Manager (potentially) =

Jgriffin: /* Dependcy Management */

2010-05-19T21:35:38Z

Dependcy Management

← Older revision		Revision as of 21:35, 19 May 2010
Line 47:		Line 47:
	* Extension Point - should be able to reuse this logging functionality in new programs without bringing along unreleated pieces (should be stand alone)		* Extension Point - should be able to reuse this logging functionality in new programs without bringing along unreleated pieces (should be stand alone)

	= ~~Dependcy~~ Management =		= Dependency Management =
	* Purpose: Allow test harnesses to create dependencies that they need in order to run, for example, a webserver		* Purpose: Allow test harnesses to create dependencies that they need in order to run, for example, a webserver
	* Provide a way to start dependent application		* Provide a way to start dependent application

Jgriffin at 21:35, 19 May 2010

2010-05-19T21:35:04Z

← Older revision		Revision as of 21:35, 19 May 2010
Line 6:		Line 6:
	I've broken down requirements into specific actions to make it easier to grapple with one problem space at a time.		I've broken down requirements into specific actions to make it easier to grapple with one problem space at a time.

	== Profile Management ==		= Profile Management =
	* Purpose: Used by the harness to manage the profile for the application under test		* Purpose: Used by the harness to manage the profile for the application under test
	* Create an empty, blank profile		* Create an empty, blank profile