by Miško Hevery & Jeremie Lenfant-engelmann
I want to edit my JavaScript code in my favorite IDE, and when I hit Ctrl-S, I want all of the tests to execute across all browsers and return the results immediately.
Command Line Control refresh the page to get my results. But browsers need an HTML file to display, which means that I have to write HTML file which loads all of my production code and my tests before I can run my tests. Now since browsers are sandboxes, the JavaScript tests runner can only report the result of the test run inside the browser window for human consumption only. This implies that 1) I cannot trigger running of the tests by hitting Ctrl-S in my IDE, I have to Alt-tab to Browser, hit refresh and Alt-tab back to the IDE and 2) I cannot display my test result in my IDE, the results are in the browser in human readable form only.Parallel Execution Instant Feedback in IDE Introducing JsTestDriver JsTestDriver captures any number of browsers from any number of platforms and turns them into slaves. As slave the browser has your production code loaded along with all of your test code. As you edit your code and hit Ctrl-S the JsTestDriver reloads only the files which you have modified into the captured browsers slaves, this greatly reduces the amount of network traffic and amount of JavaScript re-parsing which the browser has to do and therefore greatly improves the test execution time. The JsTestDriver than runs all of your test in parallel on all captured browsers. Because JavaScript APIs are non-blocking it is almost impossible for your tests to run slow, since there is nothing to block on, no network traffic and no re-parsing of the JavaScript code. As a result JsTestDriver can easily run hundreds of TestCases per second. Once the tests execute the results are sent over the network to the command which executed the tests either on the command line ready to be show in you IDE or in your continuous build.Demo
It is a very nice implementation of a great idea. Thanks for sharing!
ReplyDeleteCool stuff! Do you have any information on writing tests against asynchronous APIs?
ReplyDeleteI've made heavy use of jquery events for testing asynchronous calls with ScrewUnit, but I don't see anything here to cover that. I guess if jquery loads you could just use that on top of this.
Speaking of ScrewUnit, if you came up with a version of this that ran a BDD framework like Jasmine or ScrewUnit I'd be sold.
Nice work and thanks!
Something I really want from a JS testing framework is browser independence. I don't mean running in any browser; I mean ability to run *without* a browser, for example under a Rhino console.
ReplyDelete@Nicolas checked out Blue Ridge? The project itself is rails-centric but the concepts should be applicable to other projects without too much effort.
ReplyDeleteNicolas, you could also check the aptly named rhinounit, which runs inside rhino and can be triggered via Ant.
ReplyDelete@Nicolas: there is also CrossCheck:
ReplyDeletehttp://thefrontside.net/crosscheck
I think a unit test engine should have its UI cleanly separated just like JUnit is. Backend providing asserts and not using anything that isn't in the ECMA standard, and frontend providing a UI.
ReplyDeleteWhich could be an HTML UI relying on a browser DOM, a command line UI relying on Rhino, a runner that silently sends results using XMLHttpRequest, or a Yahoo Widget frontend.
I'm very impressed with the tight feedback loop this provides!!!
ReplyDeleteMisko, is there a way to use this in win 7?
ReplyDeleteThanks
Hey ehud, we (I work with Misko) have a new test runner called Testacular. And yep, it does work on Windows. You can check it out on https://github.com/vojtajina/testacular
ReplyDeleteThanks
ReplyDelete