Need to unit test innerHTML
Robert Sayre
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?
-Rob
Jeff Walden
> 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 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.
http://developer.mozilla.org/en/docs/Writing_xpcshell-based_unit_tests
Or is innerHTML a classinfo-provided beast that you can't test from xpcshell?
Jeff
--
Rediscover the Web!
http://snurl.com/get_firefox
Reclaim Your Inbox!
http://snurl.com/get_thunderbird
Axel Hecht
I take it that you actually need to run tests in a browser?
Maybe taking a peek at
news://news.mozilla.org:119/N4Odnd9RRaYEioXY...@mozilla.org
and
news://news.mozilla.org:119/ssednfWVSZZHvoTY...@mozilla.org,
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.
Axel
Robert Sayre
> Robert Sayre wrote:
>> 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 presume you're not aware of do_test_pending and do_test_finished?
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.
-Rob
Robert Sayre
> I think JSUnit or equivalent is the right way to do this.
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
server.
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.
https://bugzilla.mozilla.org/show_bug.cgi?id=357523
-Rob
Boris Zbarsky
> I think JSUnit or equivalent is the right way to do this.
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.
-Boris
Boris Zbarsky
>> I think JSUnit or equivalent is the right way to do this.
>
> 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
> server.
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
running manually.
5) Ability to easily tell failures apart from successes when running
manually.
6) Ability to examine and run an individual test so I can debug it when
it fails.
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
regression tests.
Items #7 and #8 argue for having the tests in Mozilla.org CVS. At least to me.
> https://bugzilla.mozilla.org/show_bug.cgi?id=357523
I'll post this comment in the bug too.
-Boris
Boris Zbarsky
>> I think JSUnit or equivalent is the right way to do this.
>
> I decided in-tree tests for this are silly. They will take way too long
Oh, question. Too long in terms of development time setting up tests, or too
long in terms of CVS pulls? Or something else?
-Boris
Dave Liebreich
> 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 don't have it running anywhere, but that should not stop you from
writing tests.
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).
--
Dave Liebreich
Test Architect, Mozilla Corporation
Robert Sayre
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.
-Rob
Boris Zbarsky
>> Oh, question. Too long in terms of development time setting up tests,
>> or too long in terms of CVS pulls? Or something else?
>
> I just meant I probably don't need them to be a "make check" type thing.
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?
>
> http://www.jsunit.net/
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. ;)
-Boris
Boris Zbarsky
> We don't have it running anywhere, but that should not stop you from
> writing tests.
>
> Mirror people.mozilla.com/~davel/jsunit), use the dom_* tests in that
> directory as examples, and write your tests.
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
missing something?
-Boris
Dave Liebreich
> 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. ;)
I'm (finally) about to set that up (at least for jsunit and reftest).
But you should write tests now.
Dave Liebreich
> I don't see a file picker, just a textfield to enter an http:// URL in.
> Am I missing something?
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.
Boris Zbarsky
> 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.
-Boris