I understand we are pretty close to making this happen, if it's not done
already. I remember discussing this with davel, and we were stuck on
some build issues with the tests for non-debug builds. I think everyone
got wrapped up in release pressure after that.
We need a non-XPCShell environment really badly. The big issue is that
XPCShell doesn't have an event loop, so nothing asynchronous can be tested.
I think it would be OK to check in an imperfect way to do this if it
will help us get moving. I can put lots of cycles in next week. Where
should I direct my efforts?
I presume you're not aware of do_test_pending and do_test_finished? The networking tests (from which the xpcshell testing harness derives) of necessity use these functions liberally.
Or is innerHTML a classinfo-provided beast that you can't test from xpcshell?
Rediscover the Web!
Reclaim Your Inbox!
I take it that you actually need to run tests in a browser?
Maybe taking a peek at
which has a link to sources of what I've been doing. Davel was quite in
favour of this, so if you could help out in this direction, that might
be a good direction.
I am, but last time I tried to use saxreader.parseAsync in XPCShell it
ended badly, and I was told that it wouldn't work because it doesn't
have an event loop. Same goes for XMLHttpRequest, I thought.
The nsIClassInfo/DOM stuff is screwed up enough in XPCShell that we need
to test in browser to get DHTML coverage anyway. For example, it's not
clear to me how I would test an HTML4 document with an .innerHTML call
that triggers CSS/image fetches or addition script execution.
I decided in-tree tests for this are silly. They will take way too long
if we have a sufficient number of them, so we should set up a central
I was able to get MochiKit's test suite usable pretty quickly.
We should set up a server that records the results of a cron job that
hits the test page.
OK. So I have to ask. Is there any documentation on the JSUnit thing? Does it
already exist? Or is it just being talked about so far?
It keeps coming up every time I want to do some DOM testcases, and I'd really
like to actually _do_ them.
> We need a non-XPCShell environment really badly.
Agreed. We need to be testing what we ship, which means classinfo and all. IMO.
At risk of sounding like a broken record, here is what I want out of our testing
setup, as a developer:
1) Ability to run the tests in an automated way (cron job, etc).
2) Ability to run the tests manually.
3) Ability to run the test suite as fast as possible.
4) Ability to easily run a small subset of the test suite when
5) Ability to easily tell failures apart from successes when running
6) Ability to examine and run an individual test so I can debug it when
7) Ability to easily add new tests.
8) Ability to easily modify existing incorrect tests.
Item #3 generally means "minimal network acess", as otherwise the network
becomes the speed bottleneck. I already have this problem with the layout
Items #7 and #8 argue for having the tests in Mozilla.org CVS. At least to me.
I'll post this comment in the bug too.
Oh, question. Too long in terms of development time setting up tests, or too
long in terms of CVS pulls? Or something else?
We don't have it running anywhere, but that should not stop you from
Mirror people.mozilla.com/~davel/jsunit), use the dom_* tests in that
directory as examples, and write your tests.
To run, load file://.../jsunit/testRunner.html, use the file picker to
select your test, and click run.
If you get stuck, as me for help (or post here).
Test Architect, Mozilla Corporation
I just meant I probably don't need them to be a "make check" type thing.
Having them under mozilla.org source control is of course desirable.
> OK. So I have to ask. Is there any documentation on the JSUnit thing?
> Does it already exist? Or is it just being talked about so far?
But the fact that davel had to hack it to get tests in event handlers,
something that MochiKit's already does, is a warning sign to me.
In my very biased opinion, it has the scent of something made for people
who spend all of their time Eclipse writing UML diagrams.
Oh, yeah. I agree. The full set of DOM tests we should end up with will
probably be way too big for that.
>> OK. So I have to ask. Is there any documentation on the JSUnit thing?
>> Does it already exist? Or is it just being talked about so far?
Yes, I know that much. My real question is whether it's in the "I can drop
tests into a given CVS location and they can then be run by other developers and
possibly run automatically on test machines" stage. ;)
OK. Once I have that, what do I do with the tests? Even if this is not running
automatically anywhere, I'd like to make it possible for developers to at least
run it manually... Which means I'd like to put the tests in CVS somewhere.
> To run, load file://.../jsunit/testRunner.html, use the file picker to
> select your test, and click run.
I don't see a file picker, just a textfield to enter an http:// URL in. Am I
I'm (finally) about to set that up (at least for jsunit and reftest).
But you should write tests now.
The browse button / filepicker only appears if the test runner was
loaded as a file:// url. If you accessed testrunner.html via http, then
it won't show up and you'll need to enter the url of the test file by hand.
Ah, ok. Gotcha.