Unable to run Jasmine in Rhino

526 views
Skip to first unread message

Gian Marco Gherardi

unread,
May 11, 2011, 5:16:03 PM5/11/11
to jasmi...@googlegroups.com
Hi, i'm trying to run Jasmine 1.0.2 in RhinoJs 1.7r2. I'm launching rhino with this command line on Windows:

java -cp js.jar org.mozilla.javascript.tools.shell.Main -opt -1 -e load('lib/test/jasmine-1.0.2/jasmine.js');

But i get this error message:

js: "lib/test/jasmine-1.0.2/jasmine.js", line 52: uncaught JavaScript runtime exception: TypeError: Cannot read property "apply" from undefined
        at lib/test/jasmine-1.0.2/jasmine.js:52
        at lib/test/jasmine-1.0.2/jasmine.js:62
        at <command>:1

Isn't Jasmine supposed to run in non browser environment?
There are some known issues with Rhino?


Julian Simpson

unread,
May 12, 2011, 3:09:59 AM5/12/11
to jasmi...@googlegroups.com
On 11 May 2011 23:16, Gian Marco Gherardi <gianmarco...@gmail.com> wrote:
Hi, i'm trying to run Jasmine 1.0.2 in RhinoJs 1.7r2. I'm launching rhino with this command line on Windows:

There's a few good examples of how to do exactly this on GitHub..


Best

J.


--
Julian Simpson
The Build Doctor Ltd.

Ben Loveridge

unread,
May 12, 2011, 12:36:28 PM5/12/11
to jasmi...@googlegroups.com
Here's another one, which I've been using for several months now. It uses Rhino + EnvJS, and includes a JUnit XML reporter which creates JUnit-style XML reports for each test. This was important for me because it makes it easy for our Hudson / Jenkins CI server to generate success / failure reports whenever a code change is pushed in and all tests are automatically executed.


- Ben



--
You received this message because you are subscribed to the Google Groups "Jasmine" group.
To post to this group, send email to jasmi...@googlegroups.com.
To unsubscribe from this group, send email to jasmine-js+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jasmine-js?hl=en.

Gian Marco Gherardi

unread,
May 12, 2011, 12:47:29 PM5/12/11
to jasmi...@googlegroups.com

Hmm interesting examples, thanks.

Seems that Jasmine assumes a browser environment, so EnvJS become a requirement for running specs on Rhino. This normally is not a problem, because the code under test is code meant to run in a browser, but the code i'm testing is not meant to run in browser so EnvJS is an unwanted dependency.

Previously i was using QUnit, i've switched to Jasmine because docs said that can run in various non browser environment, but this seems not true :-(

Gian Marco Gherardi
(sent from Android device)

Il giorno 12/mag/2011 18.36, "Ben Loveridge" <blove...@gmail.com> ha scritto:

Ben Loveridge

unread,
May 12, 2011, 12:51:44 PM5/12/11
to jasmi...@googlegroups.com
From what I've noticed, Jasmine itself has no dependencies on a browser. For example, the developers took pains to do things like jasmine.getGlobal() instead of just blindly expecting there to be a browser "window" object.

There are some other examples of people using Jasmine with node.js, which like Rhino is a standalone javascript environment, and also like Rhino does not have any browser capabilities of itself.

Here's one that seems to be actively maintained:


Maybe you could rework your code a bit to work inside Node.js instead of Rhino, and a solution like this would work for you.

- Ben


Davis Frank

unread,
May 12, 2011, 1:07:52 PM5/12/11
to jasmi...@googlegroups.com
Are you trying to test w/ Node? Or just want headless browser execution?

There is now an official jasmine npm package, which should help a bit for Node.

If you want headless browser specs, it looks like PhantomJS (from the Sencha guys) is the best at the moment. It's using Webkit w/o GUI, so you have a real DOM.

Stay away from Env.js. It hurts.

--dwf

Gian Marco Gherardi

unread,
May 12, 2011, 1:59:59 PM5/12/11
to jasmi...@googlegroups.com
Really interesting PhantomJS, i use ExtJS extensively, but i've never heard of that tools from Sencha guys

Julian Simpson

unread,
May 14, 2011, 8:17:43 AM5/14/11
to jasmi...@googlegroups.com
Hi,

On 12 May 2011 18:07, Davis Frank <dwf...@pivotallabs.com> wrote:

Stay away from Env.js. It hurts.


In what way does Env.js hurt?  I found it quite useful to support my Jasmine specs running under Rhino (IIRC, jQuery needed the DOM provided by Env), but I appreciate that my use case might have been simple.

Best,

J.



--

Davis Frank

unread,
May 14, 2011, 2:30:10 PM5/14/11
to jasmi...@googlegroups.com
There are a couple of problems with Env.js.

First is that it's a virtual DOM. Relying on it to be vald is only as good as it's ability to emulate/mock what a real browser can do. This is not a huge problem for you writing your JavaScript, but it can introduce subtle false-positives over time as DOM evolves. Which is a fine and reasonable cost as long as the emulation is maintained.

Which gets to the second problem. Env.js isn't (or wasn't, I've lost track) maintained. There are multiple forks and each one has different idiosyncratic interactions with the different frameworks out there. For example, when I last tried to get JazzMoney to work the different forks of Env.js had different problems with Prototype.js's AJAX calls. I couldn't get a combination to work.

Headless JS testing is awesome, don't get me wrong. But I'd take a look at PhantomJS and capybara-webkit for headless browsers - webkit without GUI - as an approach to deal with real DOM. And then hope, as we always do, that these projects are better maintained than Env was/is.

--dwf 

Julian Simpson

unread,
May 19, 2011, 5:27:58 PM5/19/11
to jasmi...@googlegroups.com
Hi,

On 14 May 2011 19:30, Davis Frank <dwf...@pivotallabs.com> wrote: 
First is that it's a virtual DOM. Relying on it to be vald is only as good as it's ability to emulate/mock what a real browser can do. This is not a huge problem for you writing your JavaScript, but it can introduce subtle false-positives over time as DOM evolves. Which is a fine and reasonable cost as long as the emulation is maintained.

Agreed.  I'm mostly interested in testing logic and not interactions with the browser.
 

Which gets to the second problem. Env.js isn't (or wasn't, I've lost track) maintained. There are multiple forks and each one has different idiosyncratic interactions with the different frameworks out there. For example, when I last tried to get JazzMoney to work the different forks of Env.js had different problems with Prototype.js's AJAX calls. I couldn't get a combination to work.

It looks to be the the case still, which is sad.
 

Headless JS testing is awesome, don't get me wrong. But I'd take a look at PhantomJS and capybara-webkit for headless browsers - webkit without GUI - as an approach to deal with real DOM. And then hope, as we always do, that these projects are better maintained than Env was/is.

OK.  I think you've sold me.  My main interest is in headless CI - I'm very happy running Jasmine in a browser as I make changes; but it seems like it's worth investigating PhantomJS, etc.

Thanks for sharing your experiences.

Best,

Julian.

Ben Loveridge

unread,
May 19, 2011, 5:33:28 PM5/19/11
to jasmi...@googlegroups.com
Julian,

I am currently working on integrating PhantomJS into the build process for a project I am working on. I've got a simple test runner so far, which you may be interested in, and I'm looking into options for generating JUnit-style XML output for my build server (Hudson) to consume.

If you want to take a look: https://gist.github.com/981795

Usage: phantomjs phantomjs-testrunner.js [URL]

URL can be either a http:// or file:// url

Best,

Ben

Julian Simpson

unread,
May 20, 2011, 4:02:22 AM5/20/11
to jasmi...@googlegroups.com
Hi Ben,

On 19 May 2011 22:33, Ben Loveridge <blove...@gmail.com> wrote:

I am currently working on integrating PhantomJS into the build process for a project I am working on. I've got a simple test runner so far, which you may be interested in, and I'm looking into options for generating JUnit-style XML output for my build server (Hudson) to consume.


Thank you! that looks really interesting.  I'll take a look.

Best,

Julian.

Gian Marco Gherardi

unread,
May 26, 2011, 6:26:26 PM5/26/11
to jasmi...@googlegroups.com
Jasmine depend on setTimeout, clearTimeout, setInterval and clearInterval funcions that are browser specific.

After some test, i now can make Jasmine work on Rhino WITHOUT the need for EnvJs simply by adding the following functions to the global scope

--------------------------------------------------------------------------------------
(function (global) {
    var timer = new java.util.Timer();
    var counter = 1; 
    var ids = {};

    global.setTimeout = function (fn, delay) {
        var id = counter++;
        ids[id] = new JavaAdapter(java.util.TimerTask, { run: fn });
        timer.schedule(ids[id], delay);
        return id;
    };

    global.clearTimeout = function (id) {
        ids[id].cancel();
        timer.purge();
        delete ids[id];
    };

    global.setInterval = function (fn, delay) {
        var id = counter++; 
        ids[id] = new JavaAdapter(java.util.TimerTask, { run: fn });
        timer.schedule(ids[id], delay, delay);
        return id;
    };

    global.clearInterval = global.clearTimeout;
})(this);
--------------------------------------------------------------------------------------
Reply all
Reply to author
Forward
0 new messages