DHTML / DOM / JS Test Server

VERIFIED FIXED

Status

()

Core
DOM
VERIFIED FIXED
11 years ago
9 years ago

People

(Reporter: Robert Sayre, Assigned: Robert Sayre)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(6 attachments, 4 obsolete attachments)

(Assignee)

Description

11 years ago
MochiKit has a really easy to use test suite. I was able to add a test for bug 339350 in about 5 minutes of messing around. 

We should get the server up and running under QA's watch and have a cron job hitting it. We could add a form POST at the end to send the results to a DB.

We can bootstrap with 583 tests from Bob and 1 from me.

Viewing source on the test I wrote has some informative comments. All you need to know is how to write a little JS and HTML.

view-source:http://people.mozilla.com/~sayrer/Mozilla_DHTML/tests/test_bug339350.xhtml
(Assignee)

Comment 1

11 years ago
Created attachment 243032 [details]
a tarball of the test suite (extracted from MochiKit 1.3.1 release + demo test from me)
I'm genuinely curious - what does this buy us over jsUnit?  Regardless, we should run the mochikit tests as part of our release process.

I've been working with jsUnit, modifying it to record the results via |dump()| statements, and allow test condition functions to work in event handlers.  Does the mochikit framework support recording test status in an externally-detectable manner, and can tests run in event handlers?

I've written a jsunit version of this test which you can run here

<http://people.mozilla.com/~davel/jsunit/testRunner.html?testPage=people.mozilla.com/~davel/jsunit/test_bug339350.xhtml&autoRun=true>

and view here:

view-source:http://people.mozilla.com/~davel/jsunit/test_bug339350.xhtml

the changes are
1) include a different js library
2) run in a different test harness 
3) define a function that starts with "test" to contain the test code, rather than wrapping the test code in a a |pre| with |id=test|

(Assignee)

Comment 3

11 years ago
(In reply to comment #2)
> I'm genuinely curious - what does this buy us over jsUnit? 

I don't know, because I downloaded jsUnit and I didn't understand how to set it up, even though I know how to use frameworks it's based on :)

> I've been working with jsUnit, modifying it to record the results via |dump()|
> statements

Ah, I didn't understand that this would overlap so much with your jsUnit work. I thought that was supposed to run (quickly) on the command line for devs. 

Anyway, I don't care what we use as long as we get an imperfect version running yesterday.
(Assignee)

Comment 4

11 years ago
<sayrer> why did you not use jsUnit?
   <bob> cause it was ugly
   <bob> too much boilerplate
<sayrer> boilerplate in the tests?
   <bob> yeah
<sayrer> ah, because you have to write a separate function for each test?
   <bob> yeah

this is probably less important for us, but I can see an advantage to calling ok() or is() bunch of times instead of writing separate test_* functions.
(Assignee)

Comment 5

11 years ago
(In reply to comment #2)
>  Does the mochikit framework support recording test status in an externally-detectable manner

No. But we could probably re-use your work there, if we decide to use MochiKit's framework.

> can tests run in event handlers?

Yes. See the .Async and .Signal tests.

Updated

11 years ago
OS: Mac OS X 10.3 → All
Hardware: PC → All
(In reply to comment #4)

> <sayrer> ah, because you have to write a separate function for each test?
>    <bob> yeah

um, no.

> this is probably less important for us, but I can see an advantage to calling
> ok() or is() bunch of times instead of writing separate test_* functions.

compare:

<pre id="test">
<script>
is(this, expected_this);
is(that, expected_that);
ok(the_other_thing);
</script>
</pre>

vs

<script>
function test_foo() {
assertEquals(this, expected_this);
assertEquals(that, expected_that);
assert(the_other_thing);
}
</script>

Bob has done a lot of good work with spider (his test-harness/swiss-army-knife extension).  We should also look at what can be done easily with that.

> I don't know, because I downloaded jsUnit and I didn't understand how to 
> set it up, even though I know how to use frameworks it's based on :)

Did you take a look at my sample jsunit tests?  http://people.mozilla.com/~davel/jsunit/

> Ah, I didn't understand that this would overlap so much with your
> jsUnit work. I thought that was supposed to run (quickly) on the 
> command line for devs. 

I think you may be thinking of the xpcshell-simple test harness.  That's separate from jsUnit.

> Anyway, I don't care what we use as long as we get an imperfect 
> version running yesterday.

Amen.
(Assignee)

Comment 7

11 years ago
(In reply to comment #6)
> 
> <script>
> function test_foo() {
> assertEquals(this, expected_this);
> assertEquals(that, expected_that);
> assert(the_other_thing);
> }
> </script>

I knew it would do that, but does it record each assert function call as a separate test? Does it allow a string argument describing the assertion?

> > Anyway, I don't care what we use as long as we get an imperfect 
> > version running yesterday.
> 
> Amen.

OK, what do we need from a dump file? Just PASS/FAIL? fwiw, I am confident we can get our changes upstreamed to MochiKit and it's under an MPL-compatible license. 

(In reply to comment #7) 
> I knew it would do that, but does it record each assert function call as a
> separate test? Does it allow a string argument describing the assertion?

no, but I'm not sure that is necessary, since it records the assertion that fails.  yes.
 
> OK, what do we need from a dump file? Just PASS/FAIL? fwiw, I am confident we
> can get our changes upstreamed to MochiKit and it's under an MPL-compatible
> license. 

Cool.  Give a browser installation (DIST/bin/...), we need to start the browser, run the tests, record (externally) the results, and quit the browser, and we need to do it all from the command line.

Are you willing to figure out how to do that with MochiKit's harness?

I spent time figuring out how to do that with jsUnit, but I'm not averse to tossing it in favor of something that gives us additional benefits.  jsUnit is tri-licensed like mozilla code, btw.  I don't want to use a harness with an unfriendly license if at all possible.
(Assignee)

Comment 9

11 years ago
>
> Are you willing to figure out how to do that with MochiKit's harness?
> 

Yes. Could you attach a log of your stuff? If I get stuck, we'll drop it and use jsUnit.
> Could you attach a log of your stuff? 

Dumb question: what do you mean by "log" ?

(Assignee)

Comment 11

11 years ago
(In reply to comment #10)
> > Could you attach a log of your stuff? 
> 
> Dumb question: what do you mean by "log" ?
> 

yeah, not clear on my part. just paste the console results after running jsUnit so I can see what it's supposed to do. run 'more' on log files if needed.

(Assignee)

Comment 12

11 years ago
I added a file to show tests in event handlers

view-source:http://people.mozilla.com/~sayrer/Mozilla_DHTML/tests/test_bug338679.html
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.

Certainly the page linked to in the URL field does not provide me with many of these items.... Does JSUnit?
(Assignee)

Comment 14

11 years ago
(In reply to comment #13)
> 
> 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.

It is easy to add a simple web server. Below is a Python one that depends only on the standard library. I'm sure we could do it in Perl, too.

-----------
import SimpleHTTPServer
import SocketServer

# minimal web server.  serves files relative to the
# current directory.

PORT = 8888

Handler = SimpleHTTPServer.SimpleHTTPRequestHandler
Handler.extensions_map[".xhtml"] = "application/xhtml+xml"
httpd = SocketServer.TCPServer(("", PORT), Handler)

print "serving at port", PORT
httpd.serve_forever()
-----------


> Items #7 and #8 argue for having the tests in Mozilla.org CVS.  At least to me.

Agree. But arguing about where to put it is not a low-friction way to get started.

(Assignee)

Comment 15

11 years ago
Created attachment 243110 [details] [diff] [review]
test suite with the 4 test cases on people.mozilla.com and a python HTTP server

$> python server.py 

visit http://localhost:8888/tests/ to run them locally
(Assignee)

Comment 16

11 years ago
(In reply to comment #15)
> 
> visit http://localhost:8888/tests/ to run them locally
> 

You can also use file:// URIs and just open the file, but I think we should test these with HTTP traffic on localhost, unless that really slows us down.
> It is easy to add a simple web server.

Ah, fair enough.  Good.

> Agree. But arguing about where to put it is not a low-friction way to get
> started.

Sure.  Just as long as we don't plan long-term on a One True Centralized solution as the One True Way to run tests, all's good by me.  ;)

(Assignee)

Comment 18

11 years ago
Created attachment 243128 [details]
MozillaFileLogger.js - A MochiKit Log listener that writes to a local file

MochiKit.Logging is a Log4J-like package with ERROR|INFO|DEBUG log levels and such.

This file hooks into that infrastructure and writes to a file as the tests execute.
On the httpd server front, I would much rather we do a build of thttpd and check in the actual binary into the tree, one for each platform.  http://www.acme.com/software/thttpd/ -- it's a single-binary httpd server.  This is because win32 in particular does not have python by default, and we don't depend on python for anything else.
(Assignee)

Comment 20

11 years ago
Committed logging hooks to MochiKit.SimpleTest.

http://trac.mochikit.com/browser/mochikit/trunk/tests/SimpleTest?rev=1172
(Assignee)

Comment 21

11 years ago
Created attachment 243139 [details]
improved MozillaFileLogger.js

This works when signed.applets.codebase_principal_support is true.

The HTML file to include it goes like this:

--------------------
<html>
<head>
    <script type="text/javascript" src="../lib/MochiKit/MochiKit.js"></script>
    <script type="text/javascript" src="SimpleTest/TestRunner.js"></script>
    <script type="text/javascript" src="SimpleTest/MozillaFileLogger.js"></script>
</head>
<body>
<script type="text/javascript">
TestRunner.logEnabled = true;
TestRunner.logger = new Logger();
MozillaFileLogger.init("/Users/sayrer/Desktop/test.log");
TestRunner.logger.addListener("mozLogger", null, MozillaFileLogger.getLogCallback())
TestRunner.runTests(
    'test_bug339350.xhtml',
    'test_MochiKit-Async.html'
    // ... usually more here
);
</script>
<small>Based on the <a href="http://www.mochikit.com/">MochiKit</a> unit tests.</small>
</body>
</html>

--------------------
Attachment #243128 - Attachment is obsolete: true
(Assignee)

Comment 22

11 years ago
adding a listener that dumps to the console:

------------------------

function dumpListener(msg) {
  dump("---- UNIT TESTS ---- " + msg.level + " " + msg.info.join(' ') + "\n");
}
TestRunner.logger.addListener("dumpListener", null, dumpListener);

------------------------
(Assignee)

Comment 23

11 years ago
Dave,

I think I'm just about ready to make a patch for your review, but

> Give a browser installation (DIST/bin/...)
> we need to start the browser, 
> run the tests, 
> record (externally) the results, 
> and quit the browser,
> and we need to do it all from the command line.

In the jsUnit dir, I don't see the build-fu to make that happen. Certainly your work on the start/stop scripts is universally applicable. I'm assuming this will live in /test-harness/dom-tests/ or something. What are the next steps?
starting the browser and running the tests is reusable.

you've addressed recording the results.

Next would be exiting the browser app when the tests are done, iff a config var is set.

My mods to jsUnit are in my working copy - they close the browser by loading a page that calls goQuitApplication() from bc's quit.js, if "closeWhenDone" is specified as a url parameter on the testrunner url.



(Assignee)

Comment 25

11 years ago
(In reply to comment #19)
> On the httpd server front, I would much rather we do a build of thttpd

Vlad,

This sounds preferable to me as well, provided we can get a Perl CGI running cross-platform, since we do require Perl. It doesn't look like thttpd has an equivalent to Apache's ScriptInterpreterSource directive, so we might need to hack the first line of the CGI to get the right path on each platform.

I think we'll need this so that the equivalent of Dave's dom_suite.html page can be generated by having the CGI recurse into directories based on the PATH_INFO. For example,

http://localhost:8888/unit.cgi/DOM/mutation/ 

should hit the mutation tests, while 

http://localhost:8888/unit.cgi/DOM/ 

should hit all of them.
(Assignee)

Comment 26

11 years ago
Created attachment 243160 [details]
perl script to start test run

still needs davel's closeWhenDone/quit.js hooks
(Assignee)

Comment 27

11 years ago
Created attachment 243204 [details]
testrunner html with params

this will look for three query params

1.) closeWhenDone - shut down the application after the tests run
2.) quiet - turn off the dump logger
3.) logFile - an absolute path to a log file (the file logger won't run without this)
(Assignee)

Comment 28

11 years ago
Created attachment 243207 [details]
better perl test runner
Attachment #243160 - Attachment is obsolete: true
(Assignee)

Comment 29

11 years ago
close hook added to MochiKit TestRunner, so we can call quit.js.

http://trac.mochikit.com/changeset/1173
(Assignee)

Comment 30

11 years ago
Created attachment 243260 [details] [diff] [review]
patch with dhtml tests

You'll probably have to hack some constants at the top of the runtests.pl file, but it is really close to good enough.

This patch uses the server.py file, which I think is good enough to get us going. We can cvs -rm it when we have something better. Run "python server.py" in another terminal window before running the perl script.
Attachment #243260 - Flags: review?(davel)
(Assignee)

Comment 31

11 years ago
Created attachment 243283 [details] [diff] [review]
add log levels to the patch

this adds log levels to the params. You can set the file log to DEBUG and the console to ERROR, for instance. Details on logging available here:

http://www.mochikit.com/doc/html/MochiKit/Logging.html

Right now, the tests produce about 700 lines of output if you don't set a logging level. With the console set to 'ERROR', this is what I see:

~/pserver-firefox/mozilla/tools/test-mochikit> perl runtests.pl 
Success: created profile 'dhtml_test_profile /tmp/dhtml_test_profile'
Creating profile succeeded
*** 3 ERROR FAIL | DOMAttrModified event reports correct prevValue | got "width: auto;", expected "width: 20em;"
*** 6 ERROR FAIL | XHTML innerHTML with trailing brackets ']]' | got "foo [bar", expected "foo [bar]"
 started: Mon Oct 23 22:10:42 2006
finished: Mon Oct 23 22:10:48 2006
~/pserver-firefox/mozilla/tools/test-mochikit>
Attachment #243260 - Attachment is obsolete: true
Attachment #243283 - Flags: review?(davel)
Attachment #243260 - Flags: review?(davel)
Comment on attachment 243283 [details] [diff] [review]
add log levels to the patch

I suggest that this live in mozilla/testing/test-mochikit instead of mozilla/tools/test-mochikit

I've not run this on my machines, but I'd rather get this in the tree than wait for perfection

r+ me
Attachment #243283 - Flags: review?(davel) → review+
(Assignee)

Comment 33

11 years ago
Created attachment 243509 [details] [diff] [review]
patch to check in to testing/
Attachment #243283 - Attachment is obsolete: true
(Assignee)

Comment 34

11 years ago
I added a README file.
(Assignee)

Comment 35

11 years ago
cvs commit -m "Bug 357523. DHTML / DOM / JS Test Server. r=davel" mochitest/
cvs commit: Examining mochitest
cvs commit: Examining mochitest/MochiKit
cvs commit: Examining mochitest/static
cvs commit: Examining mochitest/tests
cvs commit: Examining mochitest/tests/SimpleTest
RCS file: /cvsroot/mozilla/testing/mochitest/README.txt,v
done
Checking in mochitest/README.txt;
/cvsroot/mozilla/testing/mochitest/README.txt,v  <--  README.txt
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/gen_template.pl,v
done
Checking in mochitest/gen_template.pl;
/cvsroot/mozilla/testing/mochitest/gen_template.pl,v  <--  gen_template.pl
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/runtests.pl,v
done
Checking in mochitest/runtests.pl;
/cvsroot/mozilla/testing/mochitest/runtests.pl,v  <--  runtests.pl
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/server.py,v
done
Checking in mochitest/server.py;
/cvsroot/mozilla/testing/mochitest/server.py,v  <--  server.py
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Async.js,v
done
Checking in mochitest/MochiKit/Async.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Async.js,v  <--  Async.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Base.js,v
done
Checking in mochitest/MochiKit/Base.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Base.js,v  <--  Base.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Color.js,v
done
Checking in mochitest/MochiKit/Color.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Color.js,v  <--  Color.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Controls.js,v
done
Checking in mochitest/MochiKit/Controls.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Controls.js,v  <--  Controls.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/DOM.js,v
done
Checking in mochitest/MochiKit/DOM.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/DOM.js,v  <--  DOM.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/DateTime.js,v
done
Checking in mochitest/MochiKit/DateTime.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/DateTime.js,v  <--  DateTime.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/DragAndDrop.js,v
done
Checking in mochitest/MochiKit/DragAndDrop.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/DragAndDrop.js,v  <--  DragAndDrop.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Format.js,v
done
Checking in mochitest/MochiKit/Format.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Format.js,v  <--  Format.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Iter.js,v
done
Checking in mochitest/MochiKit/Iter.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Iter.js,v  <--  Iter.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/LICENSE.txt,v
done
Checking in mochitest/MochiKit/LICENSE.txt;
/cvsroot/mozilla/testing/mochitest/MochiKit/LICENSE.txt,v  <--  LICENSE.txt
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Logging.js,v
done
Checking in mochitest/MochiKit/Logging.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Logging.js,v  <--  Logging.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/LoggingPane.js,v
done
Checking in mochitest/MochiKit/LoggingPane.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/LoggingPane.js,v  <--  LoggingPane.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/MochiKit.js,v
done
Checking in mochitest/MochiKit/MochiKit.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/MochiKit.js,v  <--  MochiKit.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/MockDOM.js,v
done
Checking in mochitest/MochiKit/MockDOM.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/MockDOM.js,v  <--  MockDOM.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/New.js,v
done
Checking in mochitest/MochiKit/New.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/New.js,v  <--  New.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Signal.js,v
done
Checking in mochitest/MochiKit/Signal.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Signal.js,v  <--  Signal.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Sortable.js,v
done
Checking in mochitest/MochiKit/Sortable.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Sortable.js,v  <--  Sortable.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Style.js,v
done
Checking in mochitest/MochiKit/Style.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Style.js,v  <--  Style.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Test.js,v
done
Checking in mochitest/MochiKit/Test.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Test.js,v  <--  Test.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/Visual.js,v
done
Checking in mochitest/MochiKit/Visual.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/Visual.js,v  <--  Visual.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/MochiKit/__package__.js,v
done
Checking in mochitest/MochiKit/__package__.js;
/cvsroot/mozilla/testing/mochitest/MochiKit/__package__.js,v  <--  __package__.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/static/test.template.txt,v
done
Checking in mochitest/static/test.template.txt;
/cvsroot/mozilla/testing/mochitest/static/test.template.txt,v  <--  test.template.txt
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/FakeJSAN.js,v
done
Checking in mochitest/tests/FakeJSAN.js;
/cvsroot/mozilla/testing/mochitest/tests/FakeJSAN.js,v  <--  FakeJSAN.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/cli.js,v
done
Checking in mochitest/tests/cli.js;
/cvsroot/mozilla/testing/mochitest/tests/cli.js,v  <--  cli.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/index.html,v
done
Checking in mochitest/tests/index.html;
/cvsroot/mozilla/testing/mochitest/tests/index.html,v  <--  index.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/standalone.js,v
done
Checking in mochitest/tests/standalone.js;
/cvsroot/mozilla/testing/mochitest/tests/standalone.js,v  <--  standalone.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_Base.js,v
done
Checking in mochitest/tests/test_Base.js;
/cvsroot/mozilla/testing/mochitest/tests/test_Base.js,v  <--  test_Base.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_Color.js,v
done
Checking in mochitest/tests/test_Color.js;
/cvsroot/mozilla/testing/mochitest/tests/test_Color.js,v  <--  test_Color.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_DateTime.js,v
done
Checking in mochitest/tests/test_DateTime.js;
/cvsroot/mozilla/testing/mochitest/tests/test_DateTime.js,v  <--  test_DateTime.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_DragAndDrop.js,v
done
Checking in mochitest/tests/test_DragAndDrop.js;
/cvsroot/mozilla/testing/mochitest/tests/test_DragAndDrop.js,v  <--  test_DragAndDrop.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_Format.js,v
done
Checking in mochitest/tests/test_Format.js;
/cvsroot/mozilla/testing/mochitest/tests/test_Format.js,v  <--  test_Format.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_Iter.js,v
done
Checking in mochitest/tests/test_Iter.js;
/cvsroot/mozilla/testing/mochitest/tests/test_Iter.js,v  <--  test_Iter.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_Logging.js,v
done
Checking in mochitest/tests/test_Logging.js;
/cvsroot/mozilla/testing/mochitest/tests/test_Logging.js,v  <--  test_Logging.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Async.html,v
done
Checking in mochitest/tests/test_MochiKit-Async.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Async.html,v  <--  test_MochiKit-Async.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Async.json,v
done
Checking in mochitest/tests/test_MochiKit-Async.json;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Async.json,v  <--  test_MochiKit-Async.json
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Base.html,v
done
Checking in mochitest/tests/test_MochiKit-Base.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Base.html,v  <--  test_MochiKit-Base.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Color.html,v
done
Checking in mochitest/tests/test_MochiKit-Color.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Color.html,v  <--  test_MochiKit-Color.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-DOM.html,v
done
Checking in mochitest/tests/test_MochiKit-DOM.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-DOM.html,v  <--  test_MochiKit-DOM.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-DateTime.html,v
done
Checking in mochitest/tests/test_MochiKit-DateTime.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-DateTime.html,v  <--  test_MochiKit-DateTime.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-DragAndDrop.html,v
done
Checking in mochitest/tests/test_MochiKit-DragAndDrop.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-DragAndDrop.html,v  <--  test_MochiKit-DragAndDrop.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Format.html,v
done
Checking in mochitest/tests/test_MochiKit-Format.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Format.html,v  <--  test_MochiKit-Format.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Iter.html,v
done
Checking in mochitest/tests/test_MochiKit-Iter.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Iter.html,v  <--  test_MochiKit-Iter.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-JSAN.html,v
done
Checking in mochitest/tests/test_MochiKit-JSAN.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-JSAN.html,v  <--  test_MochiKit-JSAN.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Logging.html,v
done
Checking in mochitest/tests/test_MochiKit-Logging.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Logging.html,v  <--  test_MochiKit-Logging.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-MochiKit.html,v
done
Checking in mochitest/tests/test_MochiKit-MochiKit.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-MochiKit.html,v  <--  test_MochiKit-MochiKit.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Signal.html,v
done
Checking in mochitest/tests/test_MochiKit-Signal.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Signal.html,v  <--  test_MochiKit-Signal.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Style.html,v
done
Checking in mochitest/tests/test_MochiKit-Style.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Style.html,v  <--  test_MochiKit-Style.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Visual.html,v
done
Checking in mochitest/tests/test_MochiKit-Visual.html;
/cvsroot/mozilla/testing/mochitest/tests/test_MochiKit-Visual.html,v  <--  test_MochiKit-Visual.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_Signal.js,v
done
Checking in mochitest/tests/test_Signal.js;
/cvsroot/mozilla/testing/mochitest/tests/test_Signal.js,v  <--  test_Signal.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_bug338679.html,v
done
Checking in mochitest/tests/test_bug338679.html;
/cvsroot/mozilla/testing/mochitest/tests/test_bug338679.html,v  <--  test_bug338679.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_bug339350.xhtml,v
done
Checking in mochitest/tests/test_bug339350.xhtml;
/cvsroot/mozilla/testing/mochitest/tests/test_bug339350.xhtml,v  <--  test_bug339350.xhtml
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_bug355026.html,v
done
Checking in mochitest/tests/test_bug355026.html;
/cvsroot/mozilla/testing/mochitest/tests/test_bug355026.html,v  <--  test_bug355026.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/test_bug357509.html,v
done
Checking in mochitest/tests/test_bug357509.html;
/cvsroot/mozilla/testing/mochitest/tests/test_bug357509.html,v  <--  test_bug357509.html
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/SimpleTest/MozillaFileLogger.js,v
done
Checking in mochitest/tests/SimpleTest/MozillaFileLogger.js;
/cvsroot/mozilla/testing/mochitest/tests/SimpleTest/MozillaFileLogger.js,v  <--  MozillaFileLogger.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/SimpleTest/SimpleTest.js,v
done
Checking in mochitest/tests/SimpleTest/SimpleTest.js;
/cvsroot/mozilla/testing/mochitest/tests/SimpleTest/SimpleTest.js,v  <--  SimpleTest.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/SimpleTest/TestRunner.js,v
done
Checking in mochitest/tests/SimpleTest/TestRunner.js;
/cvsroot/mozilla/testing/mochitest/tests/SimpleTest/TestRunner.js,v  <--  TestRunner.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/SimpleTest/quit.js,v
done
Checking in mochitest/tests/SimpleTest/quit.js;
/cvsroot/mozilla/testing/mochitest/tests/SimpleTest/quit.js,v  <--  quit.js
initial revision: 1.1
done
RCS file: /cvsroot/mozilla/testing/mochitest/tests/SimpleTest/test.css,v
done
Checking in mochitest/tests/SimpleTest/test.css;
/cvsroot/mozilla/testing/mochitest/tests/SimpleTest/test.css,v  <--  test.css
initial revision: 1.1
done
~/firefox/mozilla/testing> 
Assignee: general → sayrer
(Assignee)

Updated

11 years ago
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 36

11 years ago
don't need to test this :)
Flags: in-testsuite-
Depends on: 455762
Blocks: 486254
Ftr, here is the cvs history part that is not in hg:

sync' from
http://svn.mochikit.com/mochikit/trunk/MochiKit/

***

(In reply to comment #1)
> extracted from MochiKit 1.3.1 release
+
(In reply to comment #35)
> cvs commit -m "Bug 357523. DHTML / DOM / JS Test Server. r=davel" mochitest/

'1.1	sayrer%gmail.com	2006-10-25 13:40	 	Bug 357523. DHTML / DOM / JS Test Server. r=davel'

This was actually a "pre-v1.4 == r1174": (v1.3.1 == r824/826, v1.4 == r1436)

"1.4"          svn r780++
Base.js        svn r1171+r1174 (== rev(s) between r1169 and r1177)

***

'1.2	sayrer%gmail.com	2006-11-06 15:48	 	Upgrade to MochiKit trunk with upstream XUL DOM code'

Then, the upgrade was to "pre-v1.4 == r1182":

Async.js       svn r1107 -> r1179
DOM.js         svn r1144 -> r1177+r1181 + undoes/supersedes custom cvs r1.2
LoggingPane.js svn r1064 -> r1180
Signal.js      svn r1169 -> r1177+r1178+r1182
+
packed.js      adds renamed+moved r1182 of ../packed/MochiKit/MochiKit.js

*****

V.Fixed
Blocks: 427500, 490955
Status: RESOLVED → VERIFIED
Why does this need to block bug 427500 and bug 490955?
You need to log in before you can comment on or make changes to this bug.