"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
