As I try to use TDD to build Fluent, I was drawn to the concept of keeping the environment pure: Fluent is intended to be a Javascript only project, so I didnt see the point of having tools that were not javascript. To this end, I wrote cuke4jas - so that I can write my feature specs in javascript. That still leaves the gaping hole of DOM testing - which most people seem to fill using something like Selenium.
Except Selenium isn't javascript alone - it minimally need Java (for Selenium RC) to run.
Or does it? Selenium core - the central piece of Selenium is STILL pure javascript; but over the years its been wrapped with the other Selenium bits to make it a complete solution that its no longer available as a separate download even. This is not without reason - the same origin policy ensures that Selenium Core will work only when you've installed it alongside the app that you want to test, which is usually not the case.
Except in cases like mine - where the app is completely in javascript, or at least completely in the browser.
It is possible to use the raw dom functions, or even libraries like Prototype, JQuery or RightJS directly with jasmine to test the DOM, but Selenium core brings to the table the full-fledged support of automating all the user's actions in a browser (with wait versions as well), so that feature specs can be written with true user actions, not imitations of those actions by calling the functions that would eventually be executed.
Design notes:
Except Selenium isn't javascript alone - it minimally need Java (for Selenium RC) to run.
Or does it? Selenium core - the central piece of Selenium is STILL pure javascript; but over the years its been wrapped with the other Selenium bits to make it a complete solution that its no longer available as a separate download even. This is not without reason - the same origin policy ensures that Selenium Core will work only when you've installed it alongside the app that you want to test, which is usually not the case.
Except in cases like mine - where the app is completely in javascript, or at least completely in the browser.
It is possible to use the raw dom functions, or even libraries like Prototype, JQuery or RightJS directly with jasmine to test the DOM, but Selenium core brings to the table the full-fledged support of automating all the user's actions in a browser (with wait versions as well), so that feature specs can be written with true user actions, not imitations of those actions by calling the functions that would eventually be executed.
Design notes:
- Extract out only the selenium-core bits from any Selenium-RC package. This would be the in selenium-remote-control-xxx\selenium-server-xxx/selenium-server.jar/core
- Subclass the TestLoop class (see HTMLTestRunner for a good implementation), and implement at least the nextCommand(), commandComplete(), commandError() and testComplete() functions. That should allow for a simple executor of selenium commands.
- Of course, TestLoop requires a CommandFactory, but the core has a default implementation that does most (all?) of the work.
- Finally, the subclass will have to take in an array of commands to execute, which nextCommand would provide when requested.
The good part of all this is that you don't need to depend on the TestRunner.html, and therefore can contain all of this within Jasmine/Species/Cuke4jas's Specrunner.html, or even open up a new window and display the app running there.
Caveat:
Caveat:
- All of this still requires a web-server; the same rules prevent file:/// resources from being used with selenium. I've fixed it with a simple webrick script, although any other web server would work just fine.
- Once more, this will work only on files served up from the same server as the selenium files are served up from.
No comments:
Post a Comment