chris clarke
software development that works…or something
Tool Support For JavaScript
August 6, 2007 on 12:57 am | In Tools n Stuff, Testing, JavaScript |Oh dear, what happened to my clever navigation and code-completion? The IDE support for JavaScript is still catching up with Java, if you have only small amounts of JavaScript you’ll be fine with TextMate or something similar. But for large class-based projects you’ll need something else.
The best thing at the moment is IntelliJ, its currently the only thing out there that can navigate across a codebase. With Aptana or Eclipse, if the method exists in another file it cannot navigate to it and you’re forced to resort to searching in files ending with *.js. Second best is Eclipse 3.3 with the JSEclipse 2.0 pre-release installed. (I’m really impressed with Eclipse 3.3 - its improved in several places - but I especially like the Quicksilver style Ctrl-3 shortcut).
How hard can unit-testing JavaScript be?
On the surface of things JavaScript seems to have a lot of the same tools that Java has for unit-testing. JSUnit is the JavaScript equivalent of JUnit and JSMock the equivalent of JMock.
The syntax of JSUnit is fine, its pretty much as you’d expect and conforms to the XUnit conventions. The key bit that’s missing is the fast feedback. When working on a class you want to be able to run the test often so you can see the immediate effects of changes you’ve made and the let the test tell you exactly whats wrong. To run a test with JSUnit, I need to open the JSUnit test runner in a browser, load my test page and then run it. Once I’ve run it, assuming its failed I get a list of tests that failed - but not the reason they failed, I need to double-click - then I get an alert telling me why the test failed. It really interrupts your flow, especially when you’re flipping between multiple classes. If you’re using an IDE with a Browser Preview tab, you can get around this problem with a little JavaScript along the lines of:
var currentLocation = "" window.location;
window.location = "file:///.../testRunner.html?testpage=" currentLocation "&autoRun=true";
(Sorry plus signs don’t seem to show up - hopefully you can get the general idea).
I’ve got this working in Eclipse by installing the EclipseHTMLEditor plugin and including the following common bit of code in all JSUnit tests:
var currentLocation = "" window.location;
if (currentLocation.indexOf("cacheBuster") < 0) {
window.location = "file:///.../testRunner.html?testpage=" currentLocation "&autoRun=true";
}
Now a test can be run by just clicking on its Preview tab.
Making a Mockery
JSMock is kind of good - at least someone’s written a mocking framework for JavaScript. As soon as you start to use it - you realize that it is by know means a mature piece of software.
It doesn’t give you any kind of useful messages, for example it will say ‘Unexpected Arguments’ but won’t tell you what the actual arguments were against the expected arguments. Similarly for an unexpected invocation, it won’t tell you what has been called and what was expected to be called. The other missing piece is support for literal objects - JSMock gets it wrong if you pass a literal object as an argument. This is basic stuff - thankfully the code is still quite small and I’ve found myself adding a lot of these features myself just to be able to use it.
The cool thing about JSMock is that because JavaScript is such a flexible language you don’t need to put your method calls in strings like in JMock 1 and you can keep using literal language (unlike in JMock 2):
server.expect().request('/index.jsp', {
method: 'get',
parameters: { userId: 'fred' },
onSuccess: function () {}
});
Another cool thing is that if I have static objects as collaborators I can mock those too:
var mockThing = mockControl.createMock(Thing);
// substitute the mock Thing for the real Thing
Thing = mockThing;
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Tool Support For JavaScript
August 6, 2007 on 12:57 am | In Tools n Stuff, Testing, JavaScript |Oh dear, what happened to my clever navigation and code-completion? The IDE support for JavaScript is still catching up with Java, if you have only small amounts of JavaScript you’ll be fine with TextMate or something similar. But for large class-based projects you’ll need something else.
The best thing at the moment is IntelliJ, its currently the only thing out there that can navigate across a codebase. With Aptana or Eclipse, if the method exists in another file it cannot navigate to it and you’re forced to resort to searching in files ending with *.js. Second best is Eclipse 3.3 with the JSEclipse 2.0 pre-release installed. (I’m really impressed with Eclipse 3.3 - its improved in several places - but I especially like the Quicksilver style Ctrl-3 shortcut).
How hard can unit-testing JavaScript be?
On the surface of things JavaScript seems to have a lot of the same tools that Java has for unit-testing. JSUnit is the JavaScript equivalent of JUnit and JSMock the equivalent of JMock.
The syntax of JSUnit is fine, its pretty much as you’d expect and conforms to the XUnit conventions. The key bit that’s missing is the fast feedback. When working on a class you want to be able to run the test often so you can see the immediate effects of changes you’ve made and the let the test tell you exactly whats wrong. To run a test with JSUnit, I need to open the JSUnit test runner in a browser, load my test page and then run it. Once I’ve run it, assuming its failed I get a list of tests that failed - but not the reason they failed, I need to double-click - then I get an alert telling me why the test failed. It really interrupts your flow, especially when you’re flipping between multiple classes. If you’re using an IDE with a Browser Preview tab, you can get around this problem with a little JavaScript along the lines of:
var currentLocation = "" window.location;
window.location = "file:///.../testRunner.html?testpage=" currentLocation "&autoRun=true";
(Sorry plus signs don’t seem to show up - hopefully you can get the general idea).
I’ve got this working in Eclipse by installing the EclipseHTMLEditor plugin and including the following common bit of code in all JSUnit tests:
var currentLocation = "" window.location;
if (currentLocation.indexOf("cacheBuster") < 0) {
window.location = "file:///.../testRunner.html?testpage=" currentLocation "&autoRun=true";
}
Now a test can be run by just clicking on its Preview tab.
Making a Mockery
JSMock is kind of good - at least someone’s written a mocking framework for JavaScript. As soon as you start to use it - you realize that it is by know means a mature piece of software.
It doesn’t give you any kind of useful messages, for example it will say ‘Unexpected Arguments’ but won’t tell you what the actual arguments were against the expected arguments. Similarly for an unexpected invocation, it won’t tell you what has been called and what was expected to be called. The other missing piece is support for literal objects - JSMock gets it wrong if you pass a literal object as an argument. This is basic stuff - thankfully the code is still quite small and I’ve found myself adding a lot of these features myself just to be able to use it.
The cool thing about JSMock is that because JavaScript is such a flexible language you don’t need to put your method calls in strings like in JMock 1 and you can keep using literal language (unlike in JMock 2):
server.expect().request('/index.jsp', {
method: 'get',
parameters: { userId: 'fred' },
onSuccess: function () {}
});
Another cool thing is that if I have static objects as collaborators I can mock those too:
var mockThing = mockControl.createMock(Thing);
// substitute the mock Thing for the real Thing
Thing = mockThing;
No Comments yet »
RSS feed for comments on this post. TrackBack URI
Leave a comment
Powered by Cheese.
RSS Entries Feed.
RSS Comments Feed
^Top^