359830 - Simple make check target for running xulrunner based unit tests

Status: RESOLVED INCOMPLETE

(Toolkit Graveyard :: XULRunner, defect)

Description

[Rob Campbell [:rc] (:robcee)]

Need a simple, XULRunner-based unit testing system built with make check (or make checkxr if windowed?). Could provide harness for testing various Moz components and running unit tests.

Comment 1

[Allan Beaufour]

Attachment: Xulrunner testtool package

Here's what I've whipped up for testing a XUL app. It's supposed to go into my xul app directory that is in mozilla/myapp

It's basically just the xpcshell-simple testharness modified with:
* runs the xulrunner application instead of xpcshell
* copies tests to <objdir>/xpi-stage/myapp/tests/<module>
* copies common files to <objdir>/xpi-stage/myapp/tests/common/

Thus I can "make check" and test my application specific components, use stuff that needs the profile running, etc. Works for me.

One thing is that the application needs to be kicked once before tests, since it needs to register the components.

Comment 2

[John Gaunt (redfive)]

Is this bug about running tests for components of xulrunner, or for running tests for XULRunner Apps?

For Songbird I have implemented a CommandLineHandler that executes js files in the  same manner as the xpcshell tests (head_ test_ tail_). It takes a comma seperated list of components to test defaulting to all if no components are sent in.

By implementing the handler I can fire up songbird normally, pass in the arg and run the tests and exit. I get access to the profile and all our songbird components as well as chrome:// urls ( we load some things via the jsloader using chrome urls at the moment ).

xpcshell was not able to completely register our components, the interfaces were not added to xpti.dat.

I haven't read up on `make check` yet and clearly my solution is a post-build step and I'm not sure how it would integrate into an automated test process (also not sure what your requirements for that kind of thing are). I would really like get a solid test harness capability built into XULRunner to allow apps to be built with testing from the ground up.

Comment 3

[Allan Beaufour]

(In reply to comment #1)
> Created an attachment (id=244901) [edit]
> Xulrunner testtool package

Forgot to mention that this is from the ZAP branch. so readFile() etc. would have to be implemented in the commandline handler directly.

(In reply to comment #2)
> Is this bug about running tests for components of xulrunner, or for running
> tests for XULRunner Apps?

Hmm, my first priority is components testing, but that's just me.
 
> For Songbird I have implemented a CommandLineHandler that executes js files in
> the  same manner as the xpcshell tests (head_ test_ tail_). It takes a comma
> seperated list of components to test defaulting to all if no components are
> sent in.
> 
> By implementing the handler I can fire up songbird normally, pass in the arg
> and run the tests and exit. I get access to the profile and all our songbird
> components as well as chrome:// urls ( we load some things via the jsloader
> using chrome urls at the moment ).

The above does some of the same, just the same way as the xpcshell-simple test harness, so you can just run "make check".

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Attachment: XULRunner-based unit test harness based on xpcshell harness

Here's what I whipped up for the JS Modules project <https://wiki.mozilla.org/Labs/JS_Modules>.  It's based on the xpcshell harness that Weave uses, which is itself derived from Mozilla's xpcshell harness.

I've used it for testing JS modules, and I also got it mostly working for testing Weave (except for one strange PSM problem--see bug 476539 for more details).  It makes some assumptions about how and from where it is being run that would probably need to change for it to fit into an automated |make check|-like step in the Mozilla build process.

Comment 5

[Benjamin Smedberg]

XULRunner has been removed from the Mozilla tree: see https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for context.

I am closing all the bugs currently in the XULRunner bugzilla component, in preparation for moving this component to the graveyard. If this bug is still valid in a XULRunner-less world, it will need to be moved to a different bugzilla component to be reopened.