Issues - relevance/blue-ridge

relevance / blue-ridge

524

Fork of jgehtland/javascript_testing
Description:	Framework for JavaScript Testing (currently a Rails Plugin) edit

Sort by: Priority | Votes | Last Updated

Loading…

12.

0 votes

fix
x

screw.unit
x

Stubbing global method (setTimeout) seems to stop test execution.
6 comments Created 5 months ago by mudphone

Title

Body
If I place the following override in a before call: before(function(){ setTimeout = function () {print('setTimeout stub');}; }); Then, the following tests do not execute as I would expect. The first following test runs, but then all the rest of the tests do not run. it("should...", function(){ print('start test1'); }); it("should...", function(){ print('start test2'); }); it("should...", function(){ print('start test3'); }); My test output looks like this: .......start test1 .setTimeout stub As you can see, test2 and test3 are never executed. Am I don't something wrong here? Thanks!
or cancel
If I place the following override in a before call:
```
  before(function(){
    setTimeout = function () {print('setTimeout stub');};
  });
```
Then, the following tests do not execute as I would expect. The first following test runs, but then all the rest of the tests do not run.
```
  it("should...", function(){
    print('start test1');
  });

  it("should...", function(){
    print('start test2');
  });

  it("should...", function(){
    print('start test3');
  });
```
My test output looks like this:
.......start test1 .setTimeout stub

As you can see, test2 and test3 are never executed. Am I don't something wrong here?

Thanks!
Comments

mudphone Mon Jun 15 18:36:33 -0700 2009 | link

Is it possibly that 'setTimeout' is a bad thing to be stubbing out (and possibly used by the Blue-Ridge framework)? If so, 'doh' (on me).

Comment
Is it possibly that 'setTimeout' is a bad thing to be stubbing out (and possibly used by the Blue-Ridge framework)? If so, 'doh' (on me).
or cancel

karnowski Wed Jun 17 08:50:42 -0700 2009 | link

We're definitely not using setTimeout in Blue Ridge, but maybe Screw.Unit is? We'll look into it.

Comment
We're definitely not using setTimeout in Blue Ridge, but maybe Screw.Unit is? We'll look into it.
or cancel

mudphone Wed Jun 17 10:04:52 -0700 2009 | link

Thanks! The night after I posted my comment, I noticed in John Resig's JS "Ninja" book, that he gives a simple example of a JS testing framework that uses setTimeout to queue tests. So, perhaps it is indeed in Screw.Unit.

Comment
Thanks! The night after I posted my comment, I noticed in John Resig's JS "Ninja" book, that he gives a simple example of a JS testing framework that uses setTimeout to queue tests. So, perhaps it is indeed in Screw.Unit.
or cancel

drnic Mon Jul 27 07:43:28 -0700 2009 | link

Does anyone have samples of testing behaviour that does take some time to complete? how do we "wait X seconds" before asserting that some behaviour has been performed?

Comment
Does anyone have samples of testing behaviour that does take some time to complete? how do we "wait X seconds" before asserting that some behaviour has been performed?
or cancel

gf3 Fri Aug 07 08:39:01 -0700 2009 | link

@drnic - Perhaps there is a better way of accomplishing this test, as JS is single-threaded. Maybe passing callback or firing an event would be better?

Comment
@drnic - Perhaps there is a better way of accomplishing this test, as JS is single-threaded. Maybe passing callback or firing an event would be better?
or cancel

wireframe Fri Aug 07 09:02:28 -0700 2009 | link

i'm stuck with the same issue. i'm trying to test code that uses setTimeout and the test completes before the code is executed. does screwunit support some kind of asyn callback for testing?

Comment
i'm stuck with the same issue. i'm trying to test code that uses setTimeout and the test completes before the code is executed. does screwunit support some kind of asyn callback for testing?
or cancel

Parsed with GitHub Flavored Markdown
13.

2 votes

fix
x

safari
x

Random asset load order in Safari causing runtime bugs
9 comments Created 4 months ago by drnic

Title

Body
In Safari 4.0.1, the generated <script> tags are correct, but Safari is loading the various assets in non-deterministic order; that is, random. So in running tests sometimes they don't run at all because jQuery or screw.builder hasn't been loaded yet. <div class="thumbnail"><a href="http://skitch.com/drnic/bse3m/application.html-random-load-order-causes-issues"><img src="http://img.skitch.com/20090702-jnbp32k5e3sht7i3tgm8b7dkmy.preview.jpg" alt="application.html - random load order causes issues" /></a><br /><span style="font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080">Uploaded with <a href="http://plasq.com/">plasq</a>'s <a href="http://skitch.com">Skitch</a>!</span></div> <div class="thumbnail"><a href="http://skitch.com/drnic/bse3q/random-load-order-causing-issues"><img src="http://img.skitch.com/20090702-38b6uu89r18je2x9fqxcdkjqp.preview.jpg" alt="random load order causing issues" /></a><br /><span style="font-family: Lucida Grande, Trebuchet, sans-serif, Helvetica, Arial; font-size: 10px; color: #808080">Uploaded with <a href="http://plasq.com/">plasq</a>'s <a href="http://skitch.com">Skitch</a>!</span></div>
or cancel
In Safari 4.0.1, the generated

Uploaded with plasq's Skitch!
Uploaded with plasq's Skitch!

Comments
karnowski Thu Jul 02 04:44:10 -0700 2009 | link

Dr Nic, thanks for pointing this out. It looks like we need to explicitly chain the requires in the blue-ridge.js file rather than just require them all asynchronously.

Comment
Dr Nic, thanks for pointing this out. It looks like we need to explicitly chain the requires in the blue-ridge.js file rather than just require them all asynchronously.
or cancel
tanzeeb Fri Jul 10 07:31:51 -0700 2009 | link
Hi,

I reordered the require's in blue-ridge.js like so:

require(BLUE_RIDGE_LIB_PREFIX + "jquery-1.3.2.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "jquery.fn.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "jquery.print.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.builder.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.matchers.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.events.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.behaviors.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "smoke.core.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "smoke.mock.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "smoke.stub.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.mocking.js", { onload: function() { require(derive_spec_name_from_current_file()); }}); }}); }}); }}); }}); }}); }}); }}); }}); }}); }});

Everything loads in order, but it tests still don't run correctly on Safari 4. Any ideas?
Comment
Hi, I reordered the require's in blue-ridge.js like so: require(BLUE_RIDGE_LIB_PREFIX + "jquery-1.3.2.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "jquery.fn.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "jquery.print.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.builder.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.matchers.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.events.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.behaviors.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "smoke.core.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "smoke.mock.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "smoke.stub.js", { onload: function() { require(BLUE_RIDGE_LIB_PREFIX + "screw.mocking.js", { onload: function() { require(derive_spec_name_from_current_file()); }}); }}); }}); }}); }}); }}); }}); }}); }}); }}); }}); Everything loads in order, but it tests still don't run correctly on Safari 4. Any ideas?
or cancel
drnic Fri Jul 10 08:15:39 -0700 2009 | link
Let's just take a moment to observe how disturbing that code looks due to the nested nature. ... I need another moment... :D

If we do get this working, it would be fun to come up with a DSL for nested require's, something like:

require('some_file.js'). then_require('dependent_file.js)

That would be sweet.

Are you coming to FutureRuby this weekend?
Comment
Let's just take a moment to observe how disturbing that code looks due to the nested nature. ... I need another moment... :D If we do get this working, it would be fun to come up with a DSL for nested require's, something like: <pre> require('some_file.js'). then_require('dependent_file.js) </pre> That would be sweet. Are you coming to FutureRuby this weekend?
or cancel
karnowski Fri Jul 10 12:41:58 -0700 2009 | link

@tanzeeb: Have you actually got it working with that? When I make that change, the files load correctly, but Safari 4.0.2 doesn't actually run any of the tests.

It looks like Safari either 1) isn't telling jQuery that the DOM is ready or 2) telling jQuery that the DOM is ready too soon.

Comment
@tanzeeb: Have you actually got it working with that? When I make that change, the files load correctly, but Safari 4.0.2 doesn't actually run any of the tests. It looks like Safari either 1) isn't telling jQuery that the DOM is ready or 2) telling jQuery that the DOM is ready too soon.
or cancel

drnic Fri Jul 10 13:01:22 -0700 2009 | link

@karnowski - @tanzeeb says above it still isn't working for him on Safari.

Hmm, interesting problem. I'm sure I've seen the tests run occasionally on Safari. Hopefully I can find some time to poke around. Stupid bug.

Comment
@karnowski - @tanzeeb says above it still isn't working for him on Safari. Hmm, interesting problem. I'm sure I've seen the tests run occasionally on Safari. Hopefully I can find some time to poke around. Stupid bug.
or cancel

karnowski Fri Jul 10 13:03:31 -0700 2009 | link

Ah, so he does! Thanks @drnic.

Comment
Ah, so he does! Thanks @drnic.
or cancel

tanzeeb Tue Jul 14 06:37:35 -0700 2009 | link

@drnic Well if you rotate your monitor 90 degrees, it looks like a very nice pyramid. ;-) Missed out on FutureRuby, did you go? How was it?

@karnowski No I still haven't figured out why it doesn't run in Safari 4. Tight deadline on my project, but once its done I'll take a look to see why. I think you're right about it being a jQuery / DOM Ready issue.

Comment
@drnic Well if you rotate your monitor 90 degrees, it looks like a very nice pyramid. ;-) Missed out on FutureRuby, did you go? How was it? @karnowski No I still haven't figured out why it doesn't run in Safari 4. Tight deadline on my project, but once its done I'll take a look to see why. I think you're right about it being a jQuery / DOM Ready issue.
or cancel

wireframe Mon Jul 20 18:06:34 -0700 2009 | link

any updates?

I'm stuck with a safari specific bug and I'd love to write some tests to verify the bugs are fixed.

Comment
any updates? I'm stuck with a safari specific bug and I'd love to write some tests to verify the bugs are fixed.
or cancel

karnowski Fri Aug 07 07:42:59 -0700 2009 | link

Updates: We can use tazeeb's fix above, but then we're still stuck with the Safari-4 problem described in issue #21. I'm leaving this issue open to add tanzeeb's fix (but with a more fluent interface on require).

Comment
Updates: We can use tazeeb's fix above, but then we're still stuck with the Safari-4 problem described in issue #21. I'm leaving this issue open to add tanzeeb's fix (but with a more fluent interface on require).
or cancel

Parsed with GitHub Flavored Markdown
15.

2 votes

feature
x

reloading fixture for each spec
7 comments Created 4 months ago by dan-manges

Title

Body
Would it be possible to reload the HTML fixture before each spec? I'm having problems because one spec will modify the dom, affecting the state for all other specs.
or cancel
Would it be possible to reload the HTML fixture before each spec? I'm having problems because one spec will modify the dom, affecting the state for all other specs.

Comments
drnic Mon Jul 20 06:19:30 -0700 2009 | link

In theory we could clone $('body').html() before each test and then restore it afterwards. Would this retain any events etc attached to all the DOM elements?

Comment
In theory we could clone $('body').html() before each test and then restore it afterwards. Would this retain any events etc attached to all the DOM elements?
or cancel

drnic Mon Jul 20 06:20:16 -0700 2009 | link

BTW, I see this issue as the only thing (and the Safari bug and acceptance of #14) stopping blue-ridge from being perfect.

Comment
BTW, I see this issue as the only thing (and the Safari bug and acceptance of #14) stopping blue-ridge from being perfect.
or cancel

karnowski Fri Aug 07 07:34:22 -0700 2009 | link

I use this:

function fixture(element) {
$('').append(element).appendTo("body"); }

function teardownFixtures() {
$("#fixtures").remove(); }

Then I call the "fixture" function in my spec and "teardownFixtures" in an after block. I've been hesitating to include this as a standard BlueRidge component, though, as it's very jQuery specific. I might have to rethink that.

Comment
I use this: function fixture(element) { $('<div id="fixtures"/>').append(element).appendTo("body"); } function teardownFixtures() { $("#fixtures").remove(); } Then I call the "fixture" function in my spec and "teardownFixtures" in an after block. I've been hesitating to include this as a standard BlueRidge component, though, as it's very jQuery specific. I might have to rethink that.
or cancel

dan-manges Mon Aug 10 17:57:36 -0700 2009 | link

@karnowski what do you think about reloading the html fixture? Is that something you would welcome in blue-ridge?

Comment
@karnowski what do you think about reloading the html fixture? Is that something you would welcome in blue-ridge?
or cancel

karnowski Sun Aug 16 18:20:53 -0700 2009 | link

@dan-manges: I'd definitely be interested.

Comment
@dan-manges: I'd definitely be interested.
or cancel
jonah-carbonfive Fri Oct 02 13:58:49 -0700 2009 | link
I've found myself adding the following to many of my specs and writing my tests to operate only on DOM elements within a #fixtures div:

var bodyContent; before(function() { if (bodyContent == null) { bodyContent = $("#fixture").html(); } else { $("#fixture").html(bodyContent); } });

I'll probably add that to my fixture and spec templates at some point but I'm not sure it makes sense to try to reload the fixture in all cases. I don't see how you could be certain to reload the fixture's state while still being able to run the tests by opening the fixture's html file. Would including the sort of reset I'm using in the default templates be useful to anyone else?
Comment
I've found myself adding the following to many of my specs and writing my tests to operate only on DOM elements within a #fixtures div: var bodyContent; before(function() { if (bodyContent == null) { bodyContent = $("#fixture").html(); } else { $("#fixture").html(bodyContent); } }); I'll probably add that to my fixture and spec templates at some point but I'm not sure it makes sense to try to reload the fixture in all cases. I don't see how you could be certain to reload the fixture's state while still being able to run the tests by opening the fixture's html file. Would including the sort of reset I'm using in the default templates be useful to anyone else?
or cancel
botandrose Mon Nov 16 16:08:57 -0800 2009 | link

Hello, folks! The following gist is a proof of concept for automatic transactional fixtures (including events).

http://gist.github.com/235556

Is there interest in developing this into a patch?

There is a dependency on jQuery... $.fn.clone(true) is doing all the heavy lifting, but isn't this a moot point since Screw Unit depends on jQuery as well?

Comment
Hello, folks! The following gist is a proof of concept for automatic transactional fixtures (including events). http://gist.github.com/235556 Is there interest in developing this into a patch? There is a dependency on jQuery... $.fn.clone(true) is doing all the heavy lifting, but isn't this a moot point since Screw Unit depends on jQuery as well?
or cancel

Parsed with GitHub Flavored Markdown
19.

0 votes

feature
x

Starting to cover blue-ridge with cucumber integration tests
1 comment Created 3 months ago by drnic

Title

Body
I've started writing integration tests for the rake tasks. Specifically there are scenarios for running 'rake test:javascripts' on: a rails project, a non-rails project, and on blue-ridge itself. With integration tests this will allow us to explore alternate compositions of technology (say trialling htmltest instead of env.js + rhino, or switching out screw.unit for jspec or whatever), but make sure that the core generators and headless test rake tasks keep working. This work is in a "features" branch (http://github.com/drnic/blue-ridge/tree/features) though this branch also includes all my other commits and merged commits from other people's branches. If you want the cucumber specific changes only, let me know, else hopefully you can pull in all the changes (some which solve other issues such as #14)
or cancel

I've started writing integration tests for the rake tasks. Specifically there are scenarios for running 'rake test:javascripts' on: a rails project, a non-rails project, and on blue-ridge itself. With integration tests this will allow us to explore alternate compositions of technology (say trialling htmltest instead of env.js + rhino, or switching out screw.unit for jspec or whatever), but make sure that the core generators and headless test rake tasks keep working.

This work is in a "features" branch (http://github.com/drnic/blue-ridge/tree/features) though this branch also includes all my other commits and merged commits from other people's branches.

If you want the cucumber specific changes only, let me know, else hopefully you can pull in all the changes (some which solve other issues such as #14)

Comments

karnowski Fri Aug 07 07:36:00 -0700 2009 | link

I've had a few people (most notably David Chelimsky & Chad Humphries) recommend this strategy too. I'll definitely take a look.

Comment
I've had a few people (most notably David Chelimsky & Chad Humphries) recommend this strategy too. I'll definitely take a look.
or cancel

Parsed with GitHub Flavored Markdown
20.

0 votes

fix
x

screw.unit
x

Matchers are too loose
2 comments Created 3 months ago by ConradIrwin

Title

Body
in javascript: 0, 0.0, null, undefined, '', ' ', etc. all evaluate to false when cast to a boolean, and almost everything else evaluates to true. the be_true and be_false method should not just check actual and !actual, but (actual === true) and (actual === false). A similar issue is present with be_null, be_undefined and equal, (false == 0, false !== 0, null == undefined, but null !== undefined).
or cancel

in javascript: 0, 0.0, null, undefined, '', ' ', etc. all evaluate to false when cast to a boolean, and almost everything else evaluates to true. the be_true and be_false method should not just check actual and !actual, but (actual === true) and (actual === false).

A similar issue is present with be_null, be_undefined and equal, (false == 0, false !== 0, null == undefined, but null !== undefined).

Comments

kristopher Wed Aug 05 11:49:05 -0700 2009 | link

Agreed the == operators type coercion is a tricky thing to deal with in javascript testing frameworks almost all the frameworks I've looked at handle their equal and be matchers differently. Some of these issues you stated are fixed in my or other peoples forks of screw-unit they just haven't been pull into blue ridge yet.

Comment
Agreed the == operators type coercion is a tricky thing to deal with in javascript testing frameworks almost all the frameworks I've looked at handle their equal and be matchers differently. Some of these issues you stated are fixed in my or other peoples forks of screw-unit they just haven't been pull into blue ridge yet.
or cancel

karnowski Fri Aug 07 07:37:50 -0700 2009 | link

I'll be updating Screw.Unit soon, so I'll try to find a patch that fixes this. Thanks for the heads up Conrad and Kristopher.

Comment
I'll be updating Screw.Unit soon, so I'll try to find a patch that fixes this. Thanks for the heads up Conrad and Kristopher.
or cancel

Parsed with GitHub Flavored Markdown
21.

5 votes

fix
x

google chrome
x

safari
x

Tests do not run in super-fast JavaScript engines (Safari 4 & Chrome)
1 comment Created 3 months ago by karnowski

Title

Body
Chad Humphries and I spent a day trying to track this down, and we haven't found it yet, but it looks like the timing of Screw.Unit, jQuery, and the BlueRidge requires are in such an order that Safari never fires the jQuery ready function. So your Screw.Unit specs never run. (Actually, it might be firing the ready function, just before BlueRidge and Screw.Unit are ready for it.) Still more work to do, any ideas welcome.
or cancel

Chad Humphries and I spent a day trying to track this down, and we haven't found it yet, but it looks like the timing of Screw.Unit, jQuery, and the BlueRidge requires are in such an order that Safari never fires the jQuery ready function. So your Screw.Unit specs never run. (Actually, it might be firing the ready function, just before BlueRidge and Screw.Unit are ready for it.)

Still more work to do, any ideas welcome.

Comments

karnowski Fri Sep 04 07:48:35 -0700 2009 | link

Looked into this a bit more, and the tests are not running in exactly the same way in Google Chrome too (both on Windows, version 2.0.172.43, and Chromium on Mac, the 2009/09/04 nightly). It appears that the require() functions and the jQuery ready() timing are out of whack on Nitro (Safari's JS engine) and V8 (Chrome's JS engine).

Comment
Looked into this a bit more, and the tests are not running in exactly the same way in Google Chrome too (both on Windows, version 2.0.172.43, and Chromium on Mac, the 2009/09/04 nightly). It appears that the require() functions and the jQuery ready() timing are out of whack on Nitro (Safari's JS engine) and V8 (Chrome's JS engine).
or cancel

Parsed with GitHub Flavored Markdown
24.

1 vote

feature
x

loadInlineScript disabled?
1 comment Created 2 months ago by 198d

Title

Body
Specs running on the command line under env.js don't execute inline <script></script> tags in the fixture body. Even if this is supposed to be the default behavior, there should be a way to re-enable inline script loading without modifying test_runner.js. We monkey-patched to fix this issue just by commenting out line 57 in test_runner.js ("loadInlineScript: function(){},"). Looks like there was a recent commit that changed the way test_runner is loading fixtures ( http://github.com/relevance/blue-ridge/commit/7617cd85fb71e5cfe0e6e54d9d8f5281e31079ea ). Just wondering what the rationale behind that particular change was...
or cancel

Specs running on the command line under env.js don't execute inline tags in the fixture body. Even if this is supposed to be the default behavior, there should be a way to re-enable inline script loading without modifying test_runner.js. We monkey-patched to fix this issue just by commenting out line 57 in test_runner.js ("loadInlineScript: function(){},").

Looks like there was a recent commit that changed the way test_runner is loading fixtures ( http://github.com/relevance/blue-ridge/commit/7617cd85fb71e5cfe0e6e54d9d8f5281e31079ea ). Just wondering what the rationale behind that particular change was...

Comments

karnowski Sun Oct 11 19:31:27 -0700 2009 | link

Hmm, I had just turned that feature off because it was conflicting in some of my tests. I hadn't thought that some folks might be relying on it. You have a great point, though, that this should be configurable. I'm marking this ticket as a feature request for a config option. Thanks!

Comment
Hmm, I had just turned that feature off because it was conflicting in some of my tests. I hadn't thought that some folks might be relying on it. You have a great point, though, that this should be configurable. I'm marking this ticket as a feature request for a config option. Thanks!
or cancel

Parsed with GitHub Flavored Markdown
28.

1 vote

Generate fixtures on the fly from the Rails itself
1 comment Created about 1 month ago by cmanfu

Title

Body
as opposed to a static HTML file which will quickly go stale. Also: add the ability to call the Rails app via ajax calls.
or cancel

as opposed to a static HTML file which will quickly go stale.

Also: add the ability to call the Rails app via ajax calls.

Comments

cmanfu Thu Oct 22 08:07:35 -0700 2009 | link

As an addendum, allow asynchronous Javascript calls to the app from tests to hit a running Rails app and return live data.

Comment
As an addendum, allow asynchronous Javascript calls to the app from tests to hit a running Rails app and return live data.
or cancel

Parsed with GitHub Flavored Markdown