relevance / blue-ridge forked from jgehtland/javascript_testing

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).

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

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.

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?

@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?

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?

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.

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?

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?

@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.

@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.

Ah, so he does! Thanks @drnic.

@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.

any updates?

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

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).

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?

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

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.

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

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

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?

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?

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

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.

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.

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).

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!

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

I get this same problem. Tests run fine but never exit unless interrupted with CTRL+C

Hi. My "test-in-one-jvm" and "local" branches both (still) "work for me". Could you let me know where exactly you pulled from and what changed from "before" to now? -- glen

Oh I bet I know what went wrong!
We're using braid to hook in the plugin and I think the blue-ridge remote was still pointing to the relevance fork. I couldn't for the life of me pull in an older version of your branch until I removed that remote definition even though I was giving your branch's github URL.

Nice work by the way! It runs way faster.