Electrolysis/Meetings/2009-08-28-testing
From MozillaWiki
< Electrolysis | Meetings(Redirected from Content Processes/Meetings/2009-08-28-testing)
- test-harness is a "sandbox" for playing with IPDL protocols
- testipcshell
- soon to be folded into xpcshell as new JS library functions
- currently have three types of processes:
- chrome: main browser process (1)
- content: process running all content (1)
- plugins: runs a plugin module, like Flash (1 per plugin module)
- mozilla-runtime is binary executed for all child processes (content and plugins)
- can we test plugins in xpcshell?
- maybe by creating an nsIWindow (?) and faking XPCOM input events
- would be a bandaid until Mochitests are working
- testipcshell can be used to send commands from the chrome process that check the effect of a previous action. for example:
- set a preference in chrome using nsIPrefMan (or whatever)
- send an ipcshell command to the child process that reads the preference and returns its value to the chrome process
- in the chrome process, assert that the value is correct
- need to make mochitests multi-process clean: content tests shouldn't touch chrome
- run mochitest-plain tests in content process
- if a test requests chrome privileges, it will die and need to be fixed
- chrome mochitests should hopefully be able to run mostly unchanged
- will we have a global browser object in Electrolysis? will it change? need to talk to UI people?
- output from Mochitests
- need to intercept stdout/stderr from child process (nsIProcess2)
- what naming scheme would be most convenient? to which directory should the log files be written?
- (future project) semi-automatically explore IPDL state machines
- easy to drive the exploration automatically; difficulty is in choosing "useful" data values to send in messages
- might be done through declarations of "interesting good" and "interesting error" values
- or by a C++/JS interface that returns the same on demand
- low-priority work
- can we improve our current crash reporting using Electrolysis?
- can we use the Necko cache in the chrome process to send more webpage information along with crash report? (in a way that also doesn't violate privacy/security?) (cjones seems to recall a research project that attempted to anononymize such info, will investigate later)
- enable Breakpad mode that monitors subprocesses
- can we gather more information in the case where the sword of Damocles wouldn't be hanging over our head in a SIGSEGV handler?
- priorities
- testing plugins
- Josh Aas is best contact
- Clint and/or Jonathan might want to join plugin-futures
- might soon have new influx of tests; talk to Josh/bsmedberg
- ramping up IPC-enabled xpcshell
- taking xpcshell tests as far as can go before mochitest is up
- get mochitest framework running
- multi-process clean mochitests
- talos! (whoops, we forgot to discuss this)
- icing-on-cakes
- testing plugins
