Stategies for Embedding QA
If there is a topic requiring multiple scripts, like Accessibility, then a test library containing general methods available to all the topical test scripts will be written. This test library (i.e. Accessibility.js) will be included in the individual scripts. At a lower level, there will be a test library containing methods available to ANY script. This library should be called something like testUtilities.js, since it will include helper or utility functions that any script could use (i.e. object creation, try/catch test procedures, posting results, request handling, etc.)
Regardless of whether we utilize the existing C++ code, we still need to create a web browser window to control the chrome. This will be a key part of the framework and will make it possible to manipulate content windows. Isolated test scripts will need to use an nsIWebBrowser object. Other objects like nsIWebNavigation can be QI'd off of nsIWebBrowser. One possibility is to build a component, either in C++ or JS, that creates a QA web browser. We would need to implement chrome interfaces that would use web browser to chrome upcalls. This would involve hooking into JS, invoking JS handlers. (TBD. speak with a developer about this).
Embedding QA believes that the soundest approach is to pursue three basic strategies:
- Development of test libraries. QA can develop a two-tier set of libraries which can be used by individual script writers. As described above, there will be a general utility library at the lowest level. One possibility is to include utility methods which could generate html templates customized for Embedding script writing. At the secondary level, Embedding area libraries (i.e. interfaces that group together into areas like accessibility, DOM, listeners) will be able to use this general library.
- Rewrite C++ test cases. QA believes that this will be much
simpler and more expedient than attempting to run C++ test cases in
a JS environment. While it's fairly straightforward to connect from JS
to C++, it's more difficult the other direction. The solution would be
to write individual .idl files for each test interface, encapsulating our
test cases, and wrap them around XPCOM objects. The XPCOM interfaces would
wrap around the C++ cases to generate JS tests.
It will be more practical to rewrite and port existing C++ test cases into JS. Of course there are some existing problems. Some interfaces like nsIClipboardCommands, nsIDOMWindow, and nsISelection are difficult to implement in JS.
Another advantage of having everything written in JS is that it will be easier to use the JS Debugger. It's true that even with C++ code, we could still traverse into deeper code with the debugger and peek into XPCOM objects, but it will be more problematic.