Jasmine 2.0 support #161

brendonrapp · 2014-02-20T02:33:20Z

I'm using guard-jasmine with the jasmine gem and server: :jasmine_gem in Rails 4.

If I browse to the Jasmine server URL, the specs run as expected.

Inside Guard, however, it appears guard-jasmine is not properly parsing the output of the jasmine_gem server:

An error occurred: Timeout waiting for the Jasmine test results!
> [#407BCA032AF4]
> [#407BCA032AF4] Jasmine2.0.0finished in 3.716s
> [#407BCA032AF4] raise exceptions 
> [#407BCA032AF4] 10 specs, 0 failures
... spec messages ...

I'm guessing the format of the output from the jasmine gem changed in 2.0, and guard-jasmine is not recognizing it as valid output? Because the specs are clearly running, but guard-jasmine isn't understanding what it gets back.

The text was updated successfully, but these errors were encountered:

netzpirat · 2014-02-20T09:09:02Z

Thanks for the report. I can confirm that guard-jasmine seems to be broken with Jasmine 2. It looks like the interface to the reporter API has been changed. I need to investigate this to get an idea what the changes are and how they impact the current design, but I do not have time this and next week.

hugocorbucci · 2014-03-05T03:06:56Z

So I've been looking at this.
Turns out Jasmine 2 has changed the messages that are sent to the reporter.
Instead of "reportSpecStarting", "reportSpecResults", "reportSuiteResults", "reportRunnerResults", "reportRunnerStarting" and "reportSuiteStarting", jasmine 2 uses:
"specStarted", "specDone", "suiteDone", "jasmineDone", "jasmineStarted" and "suiteStarted" respectively.

Unfortunately, the jasmineDone new function doesn't receive the results. However, jasmine/src/core/Env.js:165 currently receives a resultCallback with the results. Unfortunately jasmine 2.0 still doesn't hook this callback to reporter.jasmineDone.
Current Jasmine master does hook the two of them together but that's not released yet.

Seems like making guard-jasmine working with jasmine 2.0.0 will be a little hard meaning we'll have to collect results spec by spec or suite by suite.

Disclaimer: this is the first time I look at any of this so I can be completely off on this matter

netzpirat · 2014-03-05T07:59:41Z

Wow, thanks for sharing your findings.

Turns out Jasmine 2 has changed the messages that are sent to the reporter.

That's an easy one ;)

Unfortunately, the jasmineDone new function doesn't receive the results. However, jasmine/src/core/Env.js:165 currently receives a resultCallback with the results. Unfortunately jasmine 2.0 still doesn't hook this callback to reporter.jasmineDone.
Current Jasmine master does hook the two of them together but that's not released yet.

The only thing we need from the end result is the failed count, because we already collect the results on a suite basis. Getting the results failed count was just convenient, but we can get the same information from the already collected suite result or even just increment a failed spec counter, that'll be more easier since suite results are nested.

adamyonk · 2014-03-28T14:31:40Z

I'm not incredibly familiar with how jasmine works under the hood, but I'd really like to use v2 in something I'm building. Is there anything I can do to help this along?

finiteautomata · 2014-03-28T14:49:32Z

Me too... I'd love to have this working, and I'd be pleased to work on it.

netzpirat · 2014-03-29T10:39:55Z

My current understanding from @hugocorbucci findings is that the Jasmine Reporter API has changed, see his comment above. This means we need to update our Reporter implementation and ensure we can somehow collect the same information over the new API as we were able in the old API.

I'd not bother with being backward compatible, we can just increase the Guard::Jasmine version number to 2.0 and we're fine ;)

matadon · 2014-03-30T06:34:46Z

On Mar 29, 2014, at 19:39 , Michael Kessler notifications@github.com wrote:

My current understanding from @hugocorbucci findings is that the Jasmine Reporter API has changed, see his comment above. This means we need to update our Reporter implementation and ensure we can somehow collect the same information over the new API as we were able in the old API.

I'd not bother with being backward compatible, we can just increase the Guard::Jasmine version number to 2.0 and we're fine ;)

Since the messages look to be totally different, how about having a proxy object that responds to both and delegates either to the old or the new implementation? My gut says that it would be easier to test and build, and have the added advantage of being backwards compatible...

netzpirat · 2014-03-30T18:59:17Z

I'm just telling this to keep the contribution barrier low, since I don't have plans to work on this ;) I prefer having a simple solution over not having an advanced one. But I wouldn't disagree if the pull request comes with a good approach to maintain backwards compatibility.

hugocorbucci · 2014-04-02T15:21:32Z

I've been meaning and trying to write that change for a while now.
For some reason I'm not getting all the messages from jasmine 2.0 regarding the test runs. Still trying to figure out why. Haven't gotten to a point where I truly understand the development process for guard-jasmine yet. Still working on this on my (rare) spare time.

matadon · 2014-04-03T01:14:45Z

On Apr 3, 2014, at 00:21 , Hugo Corbucci notifications@github.com wrote:

I've been meaning and trying to write that change for a while now.
For some reason I'm not getting all the messages from jasmine 2.0 regarding the test runs. Still trying to figure out why. Haven't gotten to a point where I truly understand the development process for guard-jasmine yet. Still working on this on my (rare) spare time.

Same here — if I can block out some time later on in April I’ll help out.

nmccready · 2014-04-09T15:17:24Z

Any progress on this? Also to make your life easier on jasminerice I have forked it and made it support Jasmine 2.0. https://github.com/nmccready/jasminerice . Jasmine-JQuery on there is also backwards compatible with older versions of JQuery .

https://github.com/nmccready/jasmine-jquery

chrisnicola · 2014-04-21T16:39:49Z

Jasmine appears to have a new API for registering custom reporters and even has a ConsoleReporter implementation of it's own.

Does it make sense to just use that directly?

chrisnicola · 2014-04-21T17:34:39Z

Ok just reviewing this some more. It seems to me that the ConsoleReporter is an unnecessary level of abstraction here as it is just formatting console.log output which is being fed back into the Result to be reported separately in a JSON format.

It seems to me that we could just feed the results directly to to a ResultReporter which then writes the final results out as JSON as before. Skipping the need to have a separate ConsoleReporter at all.

chrisnicola · 2014-04-21T18:09:58Z

Ok so one last thought on how to do this. It seems the jsAPIReporter pretty much collects all of the results automatically. You could design this to just take suites and specs results and output them to JSON.

nmccready · 2014-05-20T17:44:25Z

Any updates?

nathanstitt · 2014-05-22T14:52:56Z

@nmccready I'm working on support for Jasmine 2. I'm using the approach you'd suggested by using the Jasmine 2 API vs scraping the console like it does now.

As part of that the JSON that is returned is different though, making the change set to the runner a bit more complex. I hope to have a version ready in the next few days for testing, and will report back when it's ready.

nmccready · 2014-05-22T14:55:15Z

Excellent, no offense I hope I beat you with my port of our rails front end application to node.js/gulp and thus no need for this any more. ;)

However if you need help let me know.

nathanstitt · 2014-05-22T14:59:56Z

CURSES!! Another one is lost to the clutches of node...

Glad you've got something working though. I'd also evaluated that solution as well, but since I'm already using Guard quite a bit, it made sense for me to fixup the runner so I could continue using it. I also couldn't get the growl integration working well with it, which Guard has excellent support for.

nathanstitt · 2014-05-23T03:00:23Z

I've just checked in a new runner that supports Jasmine 2. 392aa6d

I'll keep it on the jasmine-2 branch for the time being until it's got a bit of testing, then I'll move it to master and we'll cut a gem eventually.

If anyone who's commented on this can help test it out, that'd be great.

nmccready · 2014-05-23T14:18:14Z

I just tried your commit.

Gemfile:

gem 'guard-jasmine', :git => 'https://github.com/guard/guard-jasmine', :branch => 'jasmine-2'

Guardfile:

# A sample Guardfile
# More info at https://github.com/guard/guard#readme

guard :jasmine do
    watch(%r{spec/javascripts/jasmine/spec\.(js\.coffee|js|coffee)$}) { 'spec/javascripts' }
    watch(%r{spec/javascripts/jasmine/.+_spec\.(js\.coffee|js|coffee)$})
    watch(%r{spec/javascripts/jasmine/fixtures/.+$})
    watch(%r{app/assets/javascripts/(.+?)\.(js\.coffee|js|coffee)(?:\.\w+)*$}) { |m| "spec/javascripts/jasmine/#{ m[1] }_spec.#{ m[2] }" }
end

Error:

10:17:18 - INFO - Guard is using TerminalTitle to send notifications.
10:17:18 - INFO - Guard::Jasmine starts thin spec server on port 52606 in development environment (coverage off).
10:17:20 - INFO - Waiting for Jasmine test runner at http://localhost:52606/jasmine
10:17:31 - INFO - Run all Jasmine suites
10:17:31 - INFO - Run Jasmine suite at http://localhost:52606/jasmine
10:17:37 - ERROR - An error occurred: Javascript error encountered on Jasmine test page: SyntaxError: Unable to parse JSON string

acarpe · 2014-05-23T15:11:01Z

I just tried too. and got:

17:06:11 - ERROR - An error occurred: Javascript error encountered on
Jasmine test page: ReferenceError: Can't find variable: ConsoleOverride

On Fri, May 23, 2014 at 4:18 PM, nmccready notifications@github.com wrote:

I just tried your commit.

Gemfile:

gem 'guard-jasmine', :git => 'https://github.com/guard/guard-jasmine', :branch => 'jasmine-2'

10:17:18 - INFO - Guard is using TerminalTitle to send notifications.
10:17:18 - INFO - Guard::Jasmine starts thin spec server on port 52606 in development environment (coverage off).
10:17:20 - INFO - Waiting for Jasmine test runner at http://localhost:52606/jasmine
10:17:31 - INFO - Run all Jasmine suites
10:17:31 - INFO - Run Jasmine suite at http://localhost:52606/jasmine
10:17:37 - ERROR - An error occurred: Javascript error encountered on Jasmine test page: SyntaxError: Unable to parse JSON string

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/161#issuecomment-44014246
.

nathanstitt · 2014-05-23T15:44:01Z

Thanks for testing the branch!

Looks like I made a bone-headed mistake and missed a few stray references to an old class name. The strange thing is that all the specs still passed and my project was also able to run it’s jasmine specs fine as well. I wonder if perhaps my version of phantomjs (1.9.7) is somehow more forgiving?

Unfortunately the repo has just moved from netzpirat/guard-jasmine to guard/guard-jasmine and I’ve lost commit ability somewhere along the line. While that’s sorted, I’ve just pushed up a fix to my repo at: https://github.com/nathanstitt/guard-jasmine/tree/jasmine-2 If you'd like, please give that copy a spin.

Thanks again for taking the time to test and reporting the bug.

nmccready · 2014-05-23T18:04:51Z

@nathanstitt not sure if this will help you any but I just got jasmine2 working with gulp-jasmine . See here: https://github.com/nmccready/gulp-jasmine/tree/jasmine-npm

nmccready · 2014-05-23T22:31:50Z

After trying your latest I got:

18:30:38 - INFO - Guard is using TerminalTitle to send notifications.
18:30:38 - INFO - Guard::Jasmine starts thin spec server on port 61858 in development environment (coverage off).
18:30:41 - INFO - Waiting for Jasmine test runner at http://localhost:61858/jasmine
18:30:42 - INFO - Run all Jasmine suites
18:30:42 - INFO - Run Jasmine suite at http://localhost:61858/jasmine
18:30:49 - ERROR - An error occurred: Javascript error encountered on Jasmine test page: SyntaxError: Unable to parse JSON string

18:30:49 - INFO - Guard is now watching at

nathanstitt · 2014-05-23T22:46:57Z

@nmccready Thanks for your assistance debugging this. That error is sent by the page.onError handler when it catches an exception. It also sends back a stack trace, which it looks like I'm failing to output. I've just pushed up a change to log that, so hopefully that'll let us pinpoint what's going wrong.

If you could, can you let me know what version of phantomjs you're running? You should be able to see it by running: phantomjs --version

Like I said, I've got 1.9.7 and am not receiving any errors. I suspect it's either that or something about your specs is making the script behave badly.

Thanks again!

nmccready · 2014-05-23T22:49:39Z

Yes same version 1.9.7

nmccready · 2014-05-23T22:49:49Z

Would jasminerice bork it?

nathanstitt · 2014-05-24T00:00:52Z

No luck with testing jasminerice I'm afraid. I created a new rails project and added:

gem "jasminerice", :github=>"nmccready/jasminerice"
gem "guard-jasmine", :github=>"guard/guard-jasmin"

to the Gemfile, and:

     mount JasmineRails::Engine => '/specs' if defined?(JasmineRails)

to the routes.

I then ran rails g jasmine rice:install to install some test fixtures, and created a guard file that was the same as yours above:

guard :jasmine, debug: true do
    watch(%r{spec/javascripts/jasmine/spec\.(js\.coffee|js|coffee)$}) { 'spec/javascripts' }
    watch(%r{spec/javascripts/jasmine/.+_spec\.(js\.coffee|js|coffee)$})
    watch(%r{spec/javascripts/jasmine/fixtures/.+$})
    watch(%r{app/assets/javascripts/(.+?)\.(js\.coffee|js|coffee)(?:\.\w+)*$}) { |m| "spec/javascripts/jasmine/#{ m[1] }_spec.#{ m[2] }" }
end

I fired up guard and the specs failed since I hadn't created the assets they were requiring but I got error messages back to that effect. I then created the assets and the test specs passed successfully.

My example_spec.js.coffee file is:

#= require foo
#= require bar
#= require_self

describe "Foo", ->
  loadFixtures 'example_fixture' # located at 'spec/javascripts/fixtures/example_fixture.html.haml'
  it "it is not bar", ->
    v = new Foo()
    expect(v.bar()).toEqual(false)

describe "Bar", ->
  it "it is not foo", ->
    v = new Bar()
    expect(v.foo()).toEqual(false)


describe "Parsing Failure", ->
  it "parses", ->
    $.parseJSON("{redba:a2}")

Note, I added a spec to test out failing json parsing and it was reported as it should be.

In an effort to gather more data, I've just added a "debug" flag to guard-jasmine. My Guardfile above has an example of it.

If you could be so kind: please set debug: true in your Guardfile's options and re-run your specs. It should output the entire message it receives back from the phantomjs runner. Hopefully that will give us enough information to figure out what's broken.

Thanks so much

nmccready · 2014-05-24T00:04:03Z

Ok I'll try it out sometime this weekend thanks.

nathanstitt · 2014-05-24T00:09:42Z

Thanks! just in case it comes in handy, I've pushed my skeleton rails app that I tested with to: https://github.com/nathanstitt/guard-jasmine-rails-test

I await your testing.

nmccready · 2014-05-24T00:12:00Z

Btw I got everything working on gulp except for phhantomjs w/ jasmine or any spec framework fort that matter. Apparently that hole is still void.

https://github.com/mrhooray/gulp-mocha-phantomjs/issues/8

nmccready · 2014-05-27T16:08:17Z

@nathanstitt how do I set debug: true I do not see where this fits into the file.

Something like this with an opts object? vincentchu/guard-flopbox#1

nmccready · 2014-05-27T16:15:40Z

I modified your guard-jasmine-rails-test app with the correct configurations (which I will PR to u). Anyways I got this error:

2:14:40 - INFO - Finished in  seconds
12:14:40 - INFO - Parsing Failure
12:14:40 - INFO -   ✘ parses
12:14:40 - INFO -     ➤ SyntaxError: Unable to parse JSON string
12:14:40 - ERROR - Guard::Jasmine failed to achieve its <start>, exception was:
> [#34CAD7D83A05] NoMethodError: undefined method `split' for ["log", "\e[31mF\e[0m"]:Array
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:588:in `block in report_specdoc_logs'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:587:in `each'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:587:in `report_specdoc_logs'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:493:in `block in report_specdoc_suite'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:480:in `each'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:480:in `report_specdoc_suite'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:461:in `block in report_specdoc'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:460:in `each'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:460:in `report_specdoc'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:340:in `notify_spec_result'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:272:in `evaluate_response'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:44:in `block in run'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:43:in `each'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:43:in `inject'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine/runner.rb:43:in `run'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine.rb:150:in `run_all'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bundler/gems/guard-jasmine-311dda28ca02/lib/guard/jasmine.rb:121:in `start'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:74:in `block in run_supervised_task'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:71:in `catch'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:71:in `run_supervised_task'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:22:in `block (2 levels) in run'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:150:in `block (3 levels) in _scoped_plugins'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:148:in `each'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:148:in `block (2 levels) in _scoped_plugins'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:147:in `catch'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:147:in `block in _scoped_plugins'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:145:in `each'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:145:in `_scoped_plugins'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:21:in `block in run'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/lumberjack-1.0.5/lib/lumberjack.rb:32:in `unit_of_work'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/runner.rb:20:in `run'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/commander.rb:28:in `block in start'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/commander.rb:108:in `block in within_preserved_state'
> [#34CAD7D83A05] <internal:prelude>:10:in `synchronize'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/commander.rb:105:in `within_preserved_state'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/commander.rb:26:in `start'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/lib/guard/cli.rb:107:in `start'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/gems/guard-2.6.1/bin/guard:6:in `<top (required)>'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bin/guard:23:in `load'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bin/guard:23:in `<main>'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bin/ruby_executable_hooks:15:in `eval'
> [#34CAD7D83A05] /Users/nick.mccready/.rvm/gems/ruby-1.9.3-p545/bin/ruby_executable_hooks:15:in `<main>'
12:14:40 - INFO - Guard::Jasmine has just been fired
12:14:40 - INFO - Guard is now watching at '/Users/nick.mccready/Development/github/thirdparties/guard-jasmine-rails-test'

nathanstitt · 2014-05-27T16:36:56Z

Yeah, please link or send a PR to your copy of the guard-jasmine-rails-test app.

As for setting the debug option, you add it to the Guardfile, right after the guard :jasmine the block.

Your Guardfile's jasmine block probably looks something like this:

guard :jasmine do
 # bunch of paths
end

You can set options by modifying to be:

guard :jasmine, :debug=>true, :phantom_js_bin=>'~/bin/phantom_js'  do
 # bunch of paths
end

this will set debug to be true, and specify a custom path to phantom_js.

nmccready · 2014-05-27T17:19:47Z

I set the debug to true on my own app with a is Rails 3.2.17 , and I do not get nearly the amount of logging that you get on your app.

nmccready · 2014-05-29T15:53:21Z

Any news?

nathanstitt · 2014-05-29T23:29:10Z

Heya, I was waiting for the output from the :debug option. After the :debug options is set, guard-jasmin should output the JSON that it receives from the test runner. The length of the reply will be highly dependent on how many specs are are ran and what errors are encountered.

It seems to me like your specs are having an error that isn't getting reported correctly. I'm curious if the JSON is correctly formatted or if it's mangled somehow by the errors that were encounter. Ideally it will contain a stack trace that will allow us to pinpoint the error.

I've also just pushed up an updated version of the guard-jasmine-rails-test test app to: https://github.com/nathanstitt/guard-jasmine-rails-test

Thanks again

nathanstitt · 2014-06-08T00:32:26Z

@nmccready Have you been able to confirm if the latest changes are working for you? I'm considering merging into master but don't want to if it's still broken for you.

Thanks for your efforts thus far!

nmccready · 2014-06-11T00:26:45Z

Sorry no luck, let me give it a go again. The last week and half I have been creating a branch of our front-end environment completely ported to gulpjs which is almost done. 100% unit test passing and coverage working there with no problems via karma and jasmine.

maxcal · 2014-08-05T10:04:01Z

Here is a not so great kludge if you need a Jasmine 2.0 autorunner today:

# Gemfile
gem 'jasmine'
gem 'guard-shell'

# Guardfile
guard :shell do
  watch(%r{spec|src/.+\.js}) do |m|
    result = `rake jasmine:ci`
    failures = result.match(%r{(\d*)\sfailure[s]?})[1].to_i
    if failures == 0
      n result.lines.last, "Jasmine passed", :success
    else
      n result.lines.last, "Jasmine: #{failures} spec(s) failed", :failed
    end
    result
  end
end

nuc · 2014-08-12T07:38:14Z

The jasmine-2 branch works for me! I'm using jasmine-rails with jasmine-core 2.0.1

Thanks guys!

jscheid · 2014-11-03T12:48:10Z

Are there any plans to release the jasmine-2 branch anytime soon?

nathanstitt · 2014-11-03T15:59:29Z

Hi @jscheid
I'd love to, but it's gotten bogged down waiting on the Jasmine project to release a new version.

Right now, if a test suite is disabled, our test runner isn't notified about the start of the suite, but it is notified when the suite ends. This mismatch causes it to blow up at the end of the run. I've been unable to workaround the bug. It's been fixed in the Jasmine source at jasmine/jasmine#573, but they haven't cut a new release yet.

Once they do, then I can adjust the gemspec to require jasmine version 2.0.3 (or whatever).

The bug only affects disabled suites. Disabling individual specs works fine.

Disabling suites probably don't happen all that often, perhaps it would be better to just release as is? Assuming you've tested the branch and it works well for you, is it better to forgo being able to disable suites?

jscheid · 2014-11-03T17:17:55Z

Hi @nathanstitt, thanks for your quick reply! All makes sense, and there's no huge rush, it's just good to know that it's still on the table.

To be honest I haven't tested it, I took @nuc-gr 's word for it. I'm going to give it a whirl tomorrow to make sure. And no, we don't have disabled suites I don't think, but I don't feel it's my place to make that call... I guess it's fine to wait until Jasmine got their stuff sorted out.

chrisnicola · 2014-11-05T00:21:19Z

I've been using it for quite a while too. No serious issues so far.

jscheid · 2014-11-09T15:58:59Z

Hi @nathanstitt,

I just noticed that the commit referenced by jasmine/jasmine#573 appears to have been merged into Jasmine 2.0.2 (current is 2.0.3 released Sep 19.) Am I missing something?

    $ git show --summary --oneline 7ad2618
    7ad2618 disabled suite should still call onStart callback

    $ git tag --contains 7ad2618
    v2.0.2
    v2.0.3
    v2.0.4

    $

nathanstitt · 2014-11-10T01:50:38Z

Hm, this is interesting/weird. The releases are tagged, but the latest release on ruby gems is 2.0.2 https://rubygems.org/gems/jasmine-core

I've fired off an issue to ask the Jasmine project about it. jasmine/jasmine#701

jscheid · 2014-11-10T02:22:14Z

FWIW I was looking at the jasmine gem, not jasmine-core. https://rubygems.org/gems/jasmine -- that was released Sep 19.

nathanstitt · 2014-11-10T02:28:42Z

Yeah, but the jasmine gem pulls the Javascript (which is what we need) from jasmine-core. The gem for jasmine-core hasn't been released since 2.0.2.

jscheid · 2014-11-10T02:29:41Z

Ah, right, that makes more sense.

jscheid · 2014-11-10T02:45:32Z

@nathanstitt it looks like this PR has already been released:

$ tar xzf ~/Downloads/jasmine-core-2.0.2.gem 

$ tar xzf data.tar.gz 

$ grep -r 'calls a provided result callback with status being disabled when disabled and done' lib/jasmine-core
lib/jasmine-core/spec/core/SuiteSpec.js:  it("calls a provided result callback with status being disabled when disabled and done", function() {

$ grep -r 'can be disabled, but still calls callbacks' lib/jasmine-core
lib/jasmine-core/spec/core/SpecSpec.js:  it("can be disabled, but still calls callbacks", function() {
lib/jasmine-core/spec/core/SuiteSpec.js:  it("can be disabled, but still calls callbacks", function() {

$

jscheid · 2014-11-10T18:55:44Z

Hi again,

I've tried using the jasmine-2 branch, see Gemfile diff below. But now I'm running into a timeout, any ideas on why that would be or how I can track it down? I've tried the --debug command line option but that didn't seem to make a difference.

$ bundle exec guard-jasmine --mount=/specs
Guard::Jasmine starts thin spec server on port 54223 in test environment (coverage off).
Timeout while waiting for the server startup. You may need to increase the `:server_timeout` option.
Waiting for Jasmine test runner at http://localhost:54223/specs
Jasmine test runner isn't available: Connection refused - connect(2) for "localhost" port 54223
Guard::Jasmine stops server.
$ git diff Gemfile Gemfile.lock
diff --git a/Gemfile b/Gemfile
index 5aa09cb..9e95a95 100644
--- a/Gemfile
+++ b/Gemfile
@@ -195,19 +195,10 @@ group :development, :test do
   gem 'terminal-notifier-guard', require: RUBY_PLATFORM.include?('darwin') && 'terminal-notifier-guard'
   gem 'simplecov'
   gem 'log_buddy'
-  gem 'guard-jasmine'
+  gem 'guard-jasmine', github: 'guard/guard-jasmine', ref: 'jasmine-2'
   gem 'luhnacy'
   gem 'highline'
-
-  # Note: there is no released version of guard-jasmine compatible
-  # with jasmine 2, and the existing guard-jasmine gemspecs don't
-  # specify the incompatibility correctly. This is why we limit
-  # jasmine to major version 1 here.  This should be removed once a
-  # version of guard-jasmine with jasmine 2 support is released.  See
-  # https://github.com/guard/guard-jasmine/issues/161
-  gem 'jasmine', '~> 1.3'
-  gem 'jasmine-core', '~> 1.3'
-
+  gem 'jasmine'
   gem 'jasmine-rails'
   gem 'resque-backtrace'
 end
diff --git a/Gemfile.lock b/Gemfile.lock
index a577845..48a0205 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,4 +1,16 @@
 GIT
+  remote: git://github.com/guard/guard-jasmine.git
+  revision: d6a80e58401a782455667719bf054ef9faced35b
+  ref: jasmine-2
+  specs:
+    guard-jasmine (1.19.2)
+      childprocess
+      guard (>= 2.0.0)
+      multi_json
+      thor
+      tilt
+
+GIT
   remote: https://github.com/activeadmin/activeadmin.git
   revision: 9132da65ac40841857d8e59b06b38c63b8c2e158
   ref: 9132da65ac40841857d8e59b06b38c63b8c2e158
@@ -293,12 +305,6 @@ GEM
       lumberjack (~> 1.0)
       pry (>= 0.9.12)
       thor (>= 0.18.1)
-    guard-jasmine (1.19.2)
-      childprocess
-      guard (>= 2.0.0)
-      multi_json
-      thor
-      tilt
     guard-rspec (4.3.1)
       guard (~> 2.1)
       rspec (>= 2.14, < 4.0)
@@ -336,12 +342,12 @@ GEM
     intercom-rails (0.2.27)
       activesupport (> 3.0)
     ipaddress (0.8.0)
-    jasmine (1.3.2)
-      jasmine-core (~> 1.3.1)
-      rack (~> 1.0)
-      rspec (>= 1.3.1)
-      selenium-webdriver (>= 0.1.3)
-    jasmine-core (1.3.1)
+    jasmine (2.0.3)
+      jasmine-core (~> 2.0.0)
+      phantomjs
+      rack (>= 1.2.1)
+      rake
+    jasmine-core (2.0.2)
     jasmine-rails (0.10.2)
       jasmine-core (>= 1.3, < 3.0)
       phantomjs
@@ -612,11 +618,6 @@ GEM
       wasabi (~> 3.3.0)
     select2-rails (3.5.9.1)
       thor (~> 0.14)
-    selenium-webdriver (2.43.0)
-      childprocess (~> 0.5)
-      multi_json (~> 1.0)
-      rubyzip (~> 1.0)
-      websocket (~> 1.0)
     sexp_processor (4.4.4)
     shoulda-matchers (2.7.0)
       activesupport (>= 3.0.0)
@@ -690,7 +691,6 @@ GEM
     webmock (1.20.4)
       addressable (>= 2.3.6)
       crack (>= 0.3.2)
-    websocket (1.2.1)
     websocket-driver (0.3.5)
     xpath (2.0.0)
       nokogiri (~> 1.3)
@@ -750,7 +750,7 @@ DEPENDENCIES
   gpgme (~> 2.0)
   grit
   gruff (~> 0.5)
-  guard-jasmine
+  guard-jasmine!
   guard-rspec
   guard-zeus
   highline
@@ -759,8 +759,7 @@ DEPENDENCIES
   human_name_parser (~> 1.0)
   i18n (~> 0.6.11)
   intercom-rails (~> 0.2)
-  jasmine (~> 1.3)
-  jasmine-core (~> 1.3)
+  jasmine
   jasmine-rails
   jquery-rails (~> 3.1)
   jquery-ui-rails (~> 5.0)

jscheid · 2014-11-11T15:38:22Z

Sorry, disregard my previous comment. I've tried again from scratch today and everything is working fine, not sure what I did wrong yesterday.

nathanstitt · 2014-11-11T15:59:49Z

Hi @jscheid I actually had this open replying to you. I'm guessing what was going on is that the internal server had gotten jammed up somehow and wasn't responding to the request to run the suites.

The jasmine project replied to the ticket I'd opened. You are correct, the 2.0.2 release does have the fix included. The git tags were for npm packages.

My test app continues to fail on disabled suites though. I'm hoping to have some time later in the week to dig into it further to figure out what's going on with it.

nathanstitt · 2014-11-18T03:48:36Z

At long last, I've moved support into master and am going to be cutting a beta gem in the next few days.

I'm not sure what was going on with my testing setup, but it refused to load the proper Jasmine test runner. Removing Jasminerice and using Jasmine 2's built-in asset pipeline support resolved it for me.

I'm going to close this (very lengthy) issue for now and encourage anyone having further issues to re-open a new issue.

Thanks for everyone's patience!

brendonrapp mentioned this issue Feb 20, 2014

"Timeout waiting for the Jasmine test results!" when specs run fine #106

Closed

netzpirat changed the title ~~jasmine_gem server + Jasmine 2.0 timeout error~~ Jasmine 2.0 support Mar 27, 2014

nathanstitt mentioned this issue May 22, 2014

optional min_specs expected to run #167

Closed

nathanstitt mentioned this issue Nov 10, 2014

Ruby gem for version 2.0.4 ? jasmine/jasmine#701

Closed

nathanstitt closed this as completed Nov 18, 2014

Jasmine 2.0 support #161

Jasmine 2.0 support #161

Comments

brendonrapp commented Feb 20, 2014

netzpirat commented Feb 20, 2014

hugocorbucci commented Mar 5, 2014

netzpirat commented Mar 5, 2014

adamyonk commented Mar 28, 2014

finiteautomata commented Mar 28, 2014

netzpirat commented Mar 29, 2014

matadon commented Mar 30, 2014

netzpirat commented Mar 30, 2014

hugocorbucci commented Apr 2, 2014

matadon commented Apr 3, 2014

nmccready commented Apr 9, 2014

chrisnicola commented Apr 21, 2014

chrisnicola commented Apr 21, 2014

chrisnicola commented Apr 21, 2014

nmccready commented May 20, 2014

nathanstitt commented May 22, 2014

nmccready commented May 22, 2014

nathanstitt commented May 22, 2014

nathanstitt commented May 23, 2014

nmccready commented May 23, 2014

acarpe commented May 23, 2014

nathanstitt commented May 23, 2014

nmccready commented May 23, 2014

nmccready commented May 23, 2014

nathanstitt commented May 23, 2014

nmccready commented May 23, 2014

nmccready commented May 23, 2014

nathanstitt commented May 24, 2014

nmccready commented May 24, 2014

nathanstitt commented May 24, 2014

nmccready commented May 24, 2014

nmccready commented May 27, 2014

nmccready commented May 27, 2014

nathanstitt commented May 27, 2014

nmccready commented May 27, 2014

nmccready commented May 29, 2014

nathanstitt commented May 29, 2014

nathanstitt commented Jun 8, 2014

nmccready commented Jun 11, 2014

maxcal commented Aug 5, 2014

nuc commented Aug 12, 2014

jscheid commented Nov 3, 2014

nathanstitt commented Nov 3, 2014

jscheid commented Nov 3, 2014

chrisnicola commented Nov 5, 2014

jscheid commented Nov 9, 2014

nathanstitt commented Nov 10, 2014

jscheid commented Nov 10, 2014

nathanstitt commented Nov 10, 2014

jscheid commented Nov 10, 2014

jscheid commented Nov 10, 2014

jscheid commented Nov 10, 2014

jscheid commented Nov 11, 2014

nathanstitt commented Nov 11, 2014

nathanstitt commented Nov 18, 2014