Progress slow but steady
Charles Lowell
to rewrite the core engine to make it easier on people to hack on.
I finished the new javascript core DOM implementation which all the
browsers will use. It's much more concise than the java equivalent,
and at least on the surface appears to be quite fast (although I have
not done any strenuous benchmarks). As of last night, I had gotten
only about 25% of the core dom tests passing, but that's alright.
That's why we have them.
I also made several changes to the java test runner api in order to
make it more "plugin friendly" I'm not sure how this will play out in
practice until someone actually attempts to make an Eclipse/TextMate/
IntelliJ plugin, but one of my goals is to make it as easy as possible
to run crosscheck tests from inside code as possible.
To that end, we need to think about what is the best way to structure
our tests. There are two concerns I've identified, although there
could be more. As I see it we might as well visit the testing language
itself if we're starting from scratch, and also decide how much
control you should have for configuring your test runs inside the test
definitions themselves.
There has been a lot of branching out in testing languages with the
advent of "behavior driven" development a la rspec, the scriptaculous
testing framework, etc... There is no reason we could not bring this
style to crosscheck. Personally, I think that BDD, rather than being a
radical new paradigm, is (mostly, but not totally) about repackaging
the same old thing with a indo-european linguistic bias. After all,
not all languages are SVO. However it seems to be popular, and if we
do bring this style to crosscheck, there is no reason that it could
not used to test plain old java code because rhino allows you to
monkey-patch objects implemented in java.
What would this look like? I'm thinking something like
crosscheck.that("Basic HTML DOM Stuff Works", function(it, before) {
before(function() {
//do some setup
}
it.should("Always Have Access To The Document Object", function() {
document.shouldDefinedAndNotNull()
})
it.should("Have The Window Object As The Global Scope", function() {
window.shouldBeDefinedAndNotNull()
window.shouldEqual(this)
document.shouldEqual(window.document)
})
})
or, the same thing in classic mode:
crosscheck.suite({
setup: function() {
//do some setup
},
test_always_has_access_to_the_document_object: function() {
assertDefinedAndNotNull(document)
},
test_window_object_is_equal_to_the_global_scope: function() {
assertDefinedAndNotNull(window)
assertEquals(window, this)
assertEquals(document, window.document)
}
})
There is no reason that we cannot support both, I'm just wondering if
this is something that people are interested in at all.
The next thing to consider is what kind of control over the host
environment should be available inside the tests themselves. For
example, right now, you control at the highest level which hosts a set
of tests will run on:
Engine engine = new Engine()
engine.addFile('test1.jst')
engine.addFile('test2.jst')
engine.run(new TestListener(), "FireFox 2.0", "FireFox 3.0", "Safari
2", "IE 5.5")
This code will run all tests defined in test1.jst and test2.jst on all
the hosts listed. But is that the right place to specify that?
Maybe it should be in the tests themselves. After all there may be
some browsers/environments which certain tests don't care about.
crosscheck.suite({
runsOn: ["FireFox 2.0", "Safari 2"]
})
In fact, sometimes you might want to specify which hosts an individual
testcase inside your suite runs on. And what about doing things like
temporarily ignoring/skipping a test?
Thoughts? Opinions?
Charles