"Bob Ippolito" <[EMAIL PROTECTED]> wrote:
[snip]
>
> The question is, what else?  MochiKit's needs are pretty simple, but
> if we're switching I'd like some additional features such as Rhino/
> SpiderMonkey compatibility (preferably with a mock DOM
> implementation).  The tests will probably move out of HTML and
> into .js files for this reason.  Testing is basically all that's
> holding up the 1.2 release, so I need to have this sorted out soon.
>
> Can anyone provide recommendations for what I should look at and
> why?  Is there a need for Yet Another?  It wouldn't be hard to build
> a test framework on top of MochiKit.Base and perhaps MochiKit.Logging
> (and I've already started to), but test runners and reporting is a
> chore.
>

well I don't know if it's recommendations or shameless promotion :)

but I would advise ASTUce
http://www.burrrn.com/projects/ASTUce.html
http://www.zwetan.com/blog/buRRRn/ASTUce/Hands_on_with_ASTUce_in_JavaScript.html

-> it is not dependent on the DOM (except for a little function to
"trace"
results in DIV) or on a server-side process
-> you will not have to count the number of tests ;)
-> you will not have to even write the string names of tests
-> in fact you almost write tests as you would do it with JUnit


things that you may not like:
-> ASTUce reuse core2, and core2 has a very different design than
mochikit
  ex: you use a clone() function, core2 define a clone method for each
core
objects in their prototype
-> not tested with Rhino or with Director yet, but planed
-> for now the test runner and tests reports are very basic, but as the
design is very close to JUnit,
     that can be extended in the same way
-> you will need to rewrite all the tests

ex:
instead of having
test_MochiKit-Logging.html

you will have something as
Tests/Mochikit/LoggingTest.js

Tests.Mochikit.LoggingTest = function( name )
    {
    buRRRn.ASTUce.TestCase.call( this, name );
    }

Tests.Mochikit.LoggingTest.prototype = new buRRRn.ASTUce.TestCase();
Tests.Mochikit.LoggingTest.prototype.constructor =
Tests.Mochikit.LoggingTest;

Tests.Mochikit.LoggingTest.prototype.setUp = function()
    {
    logger.clear(); //to be sure that the logger is cleared before each
test
run
    }

Tests.Mochikit.LoggingTest.prototype.testLogger = function()
    {
    this.assertTrue( logger instanceof Logger, "global logger
installed" );
    }

Tests.Mochikit.LoggingTest.prototype.testInfo = function()
    {
    this.assertFalse( logLevelAtLeast('DEBUG')('INFO'),
'logLevelAtLeast
false' );
    this.assertFalse( logLevelAtLeast('WARNING')('INFO'),
'logLevelAtLeast
true' );
    }

Tests.Mochikit.LoggingTest.prototype.testLog = function()
    {
    //all this could be put in setUp too
    //or in another TestCase "LoggingMessagesTest" with a different
setUp
    var allMessages = [];
    logger.addListener("allMessages", null,
        bind(allMessages.push, allMessages));

    var fatalMessages = [];
    logger.addListener("fatalMessages", "FATAL",
        bind(fatalMessages.push, fatalMessages));

    var firstTwo = [];
    logger.addListener("firstTwo", null,
        bind(firstTwo.push, firstTwo));

    log( "foo" );
    var msgs = logger.getMessages();
    this.assertEquals( msgs.length, 1, 'global log() put one message in
queue' );
    this.assertEquals( allMessages, msgs, "allMessages listener" );

    var msg = msgs.pop();
    this.assertEquals( msg.info, ["foo"], "info matches" );
    this.assertEquals( msg.level, "INFO", "level matches" );

    //you should off course at the end remove the Listeners to not
polute
other tests
    //or use the tearDown method to do that automatically when the test
end
    }


ASTuce is open source and I can off course help to set it up if you
want to
use it
as for a DOM mock objects I can help with that too.

zwetan

Reply via email to