On Jul 26, 2010, at 5:46 PM, Ojan Vafai wrote:

> Then again it should be possible to re-write our script-test support
> so that this is all you need to write:
> 
> <script src="script-tests.js"></script>
> <script>
> description("foo");
> shouldBe("foo", "bar");
> </script>
> <script src="end-script-test.js"></script>
> 
> Instead of the current (cumbersome) templating system.  Should be
> possible to even get rid of the final "end-script-test.js" tag if
> we're smart.
> 
> Yes! The templating system is just too much overhead, not to mention that it 
> creates too many files. There's a few minor issues with the above though:
> 1. What if you want to include multiple js files? For example, then 
> editing/selection tests include two JS files. Maybe we should just move all 
> our JS code into one file?
> 2. The src will need to be relative, so you'll need some "../.." action. But 
> that seems OK to me. Unless we had a script that put the JS files in every 
> directory (or maybe in the resources subdirectory of every directory).

The template in fast/js is currently this:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<link rel="stylesheet" href="resources/js-test-style.css">
<script src="resources/js-test-pre.js"></script>
</head>
<body>
<p id="description"></p>
<div id="console"></div>
<script src="YOUR_JS_FILE_HERE"></script>
<script src="resources/js-test-post.js"></script>
</body>
</html>

We could reduce it to this by having the test script document.write the 
skeleton content and the stylesheet (as an inline <style> to avoid having to 
guess a path), and by using the "load" event for the post-test script:

<!DOCTYPE html>
<script src="resources/js-test-pre.js"></script>
<script src="YOUR_JS_FILE_HERE"></script>

You don't want to drop the doctype because that would put the test in quirks 
mode (probably not desired for most tests).

This is simple enough to hand-author, and you could use an inline script for 
the script, and also add other custom content to the DOM if desired.

The main problem would be getting the right path to the script file. Unless we 
duplicate it in every directory with script tests, it kinda has to be a 
relative path that depends on the directory.

For pure JS tests (mostly ones in fast/js), I think it's a good idea to keep 
the script file separate so we can keep open the possibility of running these 
tests in a command-line JS shell and not just in a full web engine.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to