Monday, July 24th, 2006

XN Test: The next Unit Testing project?

Category: JavaScript, Library, Utility

Brian McCallister is up to his usual tricks. This time he didn’t like JsUnit for a certain use case, so he created the embryo for a new test framework in JavaScript: For now let’s call it XN.

With it you can end up with a test API such as:

javascript

  1. s.test("Asynch test which succeeds", function(t) {            
  2.     t.async();
  3.    
  4.     dojo.io.bind({
  5.       url: "/Give-Me-A-404", // 404
  6.       error: function(type, thing) {
  7.         t.succeed();
  8.       }
  9.     });
  10.    
  11.   });
  12.  
  13.   s.test("Async test which should fail", function(t) {            
  14.     t,async();
  15.    
  16.     dojo.io.bind({
  17.       url: "/Give-Me-A-404", // 404
  18.       error: function(type, thing) {
  19.         t.fail("Failure is on purpose");
  20.       }
  21.     });
  22.    
  23.   });

A lot of where the design veers from standard XUnit form it is to accommodate JavaScript idiosyncrasies. For instance, if we look at the test() function we see a variable being passed in! This variable is the instance of the test case, which is also, as it so happens, the value of this in the test function.

JavaScript’s scoping bizarrity makes it much more practical to pass the test case in as an argument, that way you don’t have to capture the correct value of this, or pass around this as a context to other calls when using anonymous functions. Handy. The same thing applies to suite.

Defining it as a Dojo module is also handy, it makes building a real suite pretty easy, you just require each of the “suites” — which is why I think I’ll rename it to group or even testCase, but I hate the camel casing, so will think a bit :-)

Reporting success and failure is easy to override, the default just creates a definition list and plugs results in, like so. Not pretty, but easy to make pretty as time goes on.

The API exploration test cases are all online, but not especially polished. We’ll see where this goes. I kind of like the feel of how it is coming together. A couple things I definitely need to do though are changing failure to raise an exception rather than allow the rest of the test to continue, which will make stack trace generation for tracking down failures more useful; and add some more assertion helper functions (oh, and add the one-argument form, always including an explanation is annoying once you have stack traces to see where it came from).

It is very cool that it plugs right into Dojo and could be a nice dojo.xn library for us to use. Obviously, it is early days, but thanks for the ride Brian and keep it up!

Posted by Dion Almaer at 8:47 am
2 Comments

+++--
3.7 rating from 11 votes

2 Comments »

Comments feed TrackBack URI

I think there’s an error on line 15: t,async() should be t.async()

looks like a simple case of, “whoops my finger hit comma instead of period”

Comment by kbdamm — July 25, 2006

For unit testing our asynchronous functionality, we created yet another javascript unit testing framework we’re calling Crosscheck. The difference between crosscheck and other unit testing frameworks though is that crosscheck doesn’t need a browser to run in at all.

Instead, we simulate the different browser environments with Java, so that your tests can run quickly on any platform without requiring any particular browser to be installed.

The advantages of this approach are numerous, but it is particularly suited to asynchronous testing because the browser environment in crosscheck is a simulated one, and so it allows fine grained notification and control of runtime events such as event dispatch.

That means that you can setup your asynchronous callbacks, then synchronously invoke the simulated browser code that would invoke your asynchronous callback(such as a fetch), and then check for post conditions.

Comment by Charles Lowell — July 25, 2006

Leave a comment

You must be logged in to post a comment.