github-migration/jasmine-headless-webkit
1
0
Fork 0
Code Issues 39 Pull Requests 16 Packages Projects Releases Wiki Activity

Test w/ guard and Sprockets(-rails) w/ Rails 3.1 #11

New Issue
Closed
opened 2011-06-11 15:00:55 +00:00 by johnbintz · 18 comments
johnbintz commented 2011-06-11 15:00:55 +00:00 (Migrated from github.com)
Copy Link

Theoretically, you should be able to:

guard 'jasmine-headless-webkit', :sprockets => true do
  watch('app/assets/javascripts/**/*')
end

and then in jasmine.yml:

src_files:
  - public/sprockets.js

and it should just work, running rake sprockets:install_script before Jammit and other :run_before tasks.

Theoretically, you should be able to: ``` guard 'jasmine-headless-webkit', :sprockets => true do watch('app/assets/javascripts/**/*') end ``` and then in jasmine.yml: ``` src_files: - public/sprockets.js ``` and it should just work, running `rake sprockets:install_script` before Jammit and other `:run_before` tasks.
dnagir commented 2011-06-11 17:35:56 +00:00 (Migrated from github.com)
Copy Link

I also would love to use Rails 3.1 asset pipeline.

But I think it is a bit harder than that at least because headless-webkit can't access server (it runs from the file system).

So I guess the best bet to use it with sprockets would be to bundle exec rake assets:precompile before running the tests.

It certainly will slow-down thing.

Additionally, in theory, it should be possible to run sprockets against the assets and generate the file when headless starts, but the problem I see is that Rails environment needs to be loaded to read the sprockets configuration which is tigt in the config/application.rb + config/environments/{environment}.rb.

I also would love to use Rails 3.1 asset pipeline. But I think it is a bit harder than that at least because headless-webkit can't access server (it runs from the file system). So I guess the best bet to use it with sprockets would be to `bundle exec rake assets:precompile` before running the tests. It certainly will slow-down thing. Additionally, in theory, it should be possible to run sprockets against the assets and generate the file when headless starts, but the problem I see is that Rails environment needs to be loaded to read the sprockets configuration which is tigt in the `config/application.rb` + `config/environments/{environment}.rb`.
christiannelson commented 2011-06-11 21:31:39 +00:00 (Migrated from github.com)
Copy Link

I agree, it does seem like a tricky thing. I can describe the thing I'd hope to be able to do, maybe there's a way to get there with some creativity.

First, I'd like to be able to use jhw on a rails 3.1 project that uses the jquery-rails plugin. jquery.js is provided by that gem and my js almost always leans on jquery. I don't want to also package a non-embeded-in-a-gem version of jquery because that breaks dry. This would also apply to prototype if the prototype-rails plugin was used, or potentially any vendor supplied js that sprockets knows about.

Second, I want to be able to change jasmine specs, or the code under test (coffeescript), and have guard do what needs to be done to rerun the js specs. Reimplementing the asset pipeline in jhw doesn't make sense, since that's not dry either.

It does seem like running "rake assets:clean assets:precompile" before running jasmine specs (only if stuff under app/assets/javascript changed) and including public/assets/application*.js in jasmine.yml would do the trick. With a very vanilla rails 3.1 application that takes 4.5s (wall time) to perform (on my mbp). Not awful but not great. It's unclear to me how it will scale.

What do you guys think, is it worth a try?

I agree, it does seem like a tricky thing. I can describe the thing I'd hope to be able to do, maybe there's a way to get there with some creativity. First, I'd like to be able to use jhw on a rails 3.1 project that uses the jquery-rails plugin. jquery.js is provided by that gem and my js almost always leans on jquery. I don't want to also package a non-embeded-in-a-gem version of jquery because that breaks dry. This would also apply to prototype if the prototype-rails plugin was used, or potentially any vendor supplied js that sprockets knows about. Second, I want to be able to change jasmine specs, or the code under test (coffeescript), and have guard do what needs to be done to rerun the js specs. Reimplementing the asset pipeline in jhw doesn't make sense, since that's not dry either. It does seem like running "rake assets:clean assets:precompile" before running jasmine specs (only if stuff under app/assets/javascript changed) and including public/assets/application*.js in jasmine.yml would do the trick. With a very vanilla rails 3.1 application that takes 4.5s (wall time) to perform (on my mbp). Not awful but not great. It's unclear to me how it will scale. What do you guys think, is it worth a try?
johnbintz commented 2011-06-12 03:22:15 +00:00 (Migrated from github.com)
Copy Link

I can't see any other solution for now, until it's easier to do the whole asset path thing without Rails. If it works, I'll add it to guard-jasmine-headless-webkit, or will gladly take a pull request to add it in.

I can't see any other solution for now, until it's easier to do the whole asset path thing without Rails. If it works, I'll add it to guard-jasmine-headless-webkit, or will gladly take a pull request to add it in.
johnbintz commented 2011-06-12 14:44:32 +00:00 (Migrated from github.com)
Copy Link

OK, there's an issue with just running rake assets:precompile, in that, with every change, the file name is different (thanks MD5!). So after much cursing, I found the place to duck punch Sprockets so that one can use their own digest generation scheme...which in this case, always generates the digest "test":

cc619466df

So try the duck-punch-sprockets branch and run rake assets:precompile:for_testing and point jasmine.yml at public/assets/*-test.js and see if that works. It should. I think.

OK, there's an issue with just running `rake assets:precompile`, in that, with every change, the file name is different (thanks MD5!). So after much cursing, I found the place to duck punch Sprockets so that one can use their own digest generation scheme...which in this case, always generates the digest "test": https://github.com/johnbintz/jasmine-headless-webkit/commit/cc619466dffaa9f31d78a7aca6ba2917b412df7a So try the `duck-punch-sprockets` branch and run `rake assets:precompile:for_testing` and point jasmine.yml at `public/assets/*-test.js` and see if that works. It should. I think.
johnbintz commented 2011-06-14 14:45:45 +00:00 (Migrated from github.com)
Copy Link

Anyone try this out yet? I'd love to get this out there if it's working well for everyone. It seems to be OK for me, but I probably don't have as much experience w/ Rails 3.1 as youall seem to have at the moment.

Anyone try this out yet? I'd love to get this out there if it's working well for everyone. It seems to be OK for me, but I probably don't have as much experience w/ Rails 3.1 as youall seem to have at the moment.
christiannelson commented 2011-06-14 17:47:11 +00:00 (Migrated from github.com)
Copy Link

First off, thanks for working on this and being patient... I'm on vacation in Mexico with the family and don't have a lot of time for hacking. :)

Looking at the application-.js that's produced from "rake assets:precompile" I see all of the js aggregated in there. I'm not sure why all of the files are also precompile individually. So, in my jasmine.yml I included only "public/assets/application-*.js". That works great. I haven't yet figured out how to run rake assets:clean assets:precompile (clean to remove dups) automatically before guard-jasmine-headless-webkit. Guard hooks/callbacks live in a branch that hasn't been merged into master yet. Any ideas?

The upshot is that I don't think you need to duck-punch anything. :) I'll be poking and playing a little each night after my munchkins go to bed. My plan it to share my findings once I feel like I've found a great setup for rails 3.1 and javascript testing (and test driving).

First off, thanks for working on this and being patient... I'm on vacation in Mexico with the family and don't have a lot of time for hacking. :) Looking at the application-<hash>.js that's produced from "rake assets:precompile" I see all of the js aggregated in there. I'm not sure why all of the files are also precompile individually. So, in my jasmine.yml I included only "public/assets/application-*.js". That works great. I haven't yet figured out how to run `rake assets:clean assets:precompile` (clean to remove dups) automatically before guard-jasmine-headless-webkit. Guard hooks/callbacks live in a branch that hasn't been merged into master yet. Any ideas? The upshot is that I don't think you need to duck-punch anything. :) I'll be poking and playing a little each night after my munchkins go to bed. My plan it to share my findings once I feel like I've found a great setup for rails 3.1 and javascript testing (and test driving).
johnbintz commented 2011-06-14 18:15:58 +00:00 (Migrated from github.com)
Copy Link

For running before in guard-jasmine-headless-webkit, use :run_before:

guard 'jasmine-headless-webkit', :run_before => 'rake assets:clean assets:precompile' do
  ...stuff...
 end

I haven't played with hooks/callbacks yet in the other Guard branch. Plus, I like punching ducks.

For running before in `guard-jasmine-headless-webkit`, use `:run_before`: ``` guard 'jasmine-headless-webkit', :run_before => 'rake assets:clean assets:precompile' do ...stuff... end ``` I haven't played with hooks/callbacks yet in the other Guard branch. Plus, I like punching ducks.
christiannelson commented 2011-06-14 18:25:58 +00:00 (Migrated from github.com)
Copy Link

Who doesn't love a good duck punch every once in a while. :) (thanks for
the run_before tip!)

On Tue, Jun 14, 2011 at 1:15 PM, johnbintz <
reply@reply.github.com>wrote:

For running before in guard-jasmine-headless-webkit, use :run_before:

guard 'jasmine-headless-webkit', :run_before => 'rake assets:clean
assets:precompile' do
...stuff...
end

I haven't played with hooks/callbacks yet in the other Guard branch. Plus,
I like punching ducks.

Reply to this email directly or view it on GitHub:

https://github.com/johnbintz/jasmine-headless-webkit/issues/11#issuecomment-1368015

Christian Nelson | Carbon Five | 415.546.0500 | christian@carbonfive.com

Who doesn't love a good duck punch every once in a while. :) (thanks for the run_before tip!) On Tue, Jun 14, 2011 at 1:15 PM, johnbintz < reply@reply.github.com>wrote: > For running before in `guard-jasmine-headless-webkit`, use `:run_before`: > > guard 'jasmine-headless-webkit', :run_before => 'rake assets:clean > assets:precompile' do > ...stuff... > end > > I haven't played with hooks/callbacks yet in the other Guard branch. Plus, > I like punching ducks. > > ## > > Reply to this email directly or view it on GitHub: > > https://github.com/johnbintz/jasmine-headless-webkit/issues/11#issuecomment-1368015 ## Christian Nelson | Carbon Five | 415.546.0500 | christian@carbonfive.com
dnagir commented 2011-06-16 22:42:51 +00:00 (Migrated from github.com)
Copy Link

@christiannelson RE files being generated AND included into the application-*.js: I override config.assets.precompile = ['application.js', 'application.css', 'ie.css'] in the config/application.rb. It makes explicit what assets should be compiled.

@johnbintz To include the file in jasmine.yml, I just wildacard the MD5 hash, so it doesn't matter what the digest is: application-*.js or similar works great.

What I currently do - use the Guard to precompile the assests:

  module ::Guard
    class AssetsCompiler < ::Guard::Guard
      def run_on_change(path=[])
        puts 'Compiling rails assets'
        system 'rm -rf public/assets/ ; bundle exec rake assets:precompile'
        tree = `tree public/assets`
        puts tree
        Notifier::notify tree.split(/\n/).last, :title => 'Assets compiled'
        true
      end

      def start; run_on_change; end
      def reload; true; end
    end
  end


  guard 'assets-compiler' do
    watch(%r{^app/assets/.+$})
    #watch('app/assets/javascripts/application.js')
    watch('config/application.rb')
  end

You should be able to literally copy-paste it into your Guardfile. The main problem I have with it is that it is pretty slow (10 secs) as it needs to run the rake task loading rails. Perhaps running the rake task from the guard would improve things.

@christiannelson RE files being generated AND included into the `application-*.js`: I override `config.assets.precompile = ['application.js', 'application.css', 'ie.css']` in the `config/application.rb`. It makes explicit what assets should be compiled. @johnbintz To include the file in `jasmine.yml`, I just wildacard the MD5 hash, so it doesn't matter what the digest is: `application-*.js` or similar works great. What I currently do - use the Guard to precompile the assests: ``` module ::Guard class AssetsCompiler < ::Guard::Guard def run_on_change(path=[]) puts 'Compiling rails assets' system 'rm -rf public/assets/ ; bundle exec rake assets:precompile' tree = `tree public/assets` puts tree Notifier::notify tree.split(/\n/).last, :title => 'Assets compiled' true end def start; run_on_change; end def reload; true; end end end guard 'assets-compiler' do watch(%r{^app/assets/.+$}) #watch('app/assets/javascripts/application.js') watch('config/application.rb') end ``` You should be able to literally copy-paste it into your `Guardfile`. The _main problem_ I have with it is that it is pretty slow (10 secs) as it needs to run the rake task loading rails. Perhaps running the rake task from the guard would improve things.
johnbintz commented 2011-06-16 23:28:49 +00:00 (Migrated from github.com)
Copy Link

@dnagir If you wanted to perform the same action as the Rake task from Guard, you'd have to load in enough of the Rails app to get at Rails.application.assets. Then just do this:

https://github.com/rails/rails/blob/master/railties/lib/rails/tasks/assets.rake#L3

It would definitely be a lot faster that way. At that point, you can probably make this into a separate fully-fledged Guard, as I'm recommending that users do for Jammit support from now on.

@dnagir If you wanted to perform the same action as the Rake task from Guard, you'd have to load in enough of the Rails app to get at `Rails.application.assets`. Then just do this: https://github.com/rails/rails/blob/master/railties/lib/rails/tasks/assets.rake#L3 It would definitely be a lot faster that way. At that point, you can probably make this into a separate fully-fledged Guard, as I'm recommending that users do for Jammit support from now on.
dnagir commented 2011-06-17 00:08:34 +00:00 (Migrated from github.com)
Copy Link

Yeah. That makes sense.

Another option is to use Spork. Most of the time I already run spork for RSpec. But not sure how to merry those 2 things.

Yeah. That makes sense. Another option is to use Spork. Most of the time I already run spork for RSpec. But not sure how to merry those 2 things.
johnbintz commented 2011-06-17 00:11:48 +00:00 (Migrated from github.com)
Copy Link

If you can get Spork to do that, that would definitely make it faster. Regardless, if you can get that Guard for asset compilation to be fully-fledged and ready to plug in before JHW, even if it is a bit slow, it will certainly help solve a very big problem with Rails 3.1. :)

If you can get Spork to do that, that would definitely make it faster. Regardless, if you can get that Guard for asset compilation to be fully-fledged and ready to plug in before JHW, even if it is a bit slow, it will certainly help solve a very big problem with Rails 3.1. :)
dnagir commented 2011-06-17 00:27:49 +00:00 (Migrated from github.com)
Copy Link

I will try to hack on it this weekend. Will update here if I'll succeed :)

I will try to hack on it this weekend. Will update here if I'll succeed :)
dnagir commented 2011-06-17 13:42:31 +00:00 (Migrated from github.com)
Copy Link

Done with the new guard gem: guard-rails-assets. It works well for me and should be a pretty good start.

Done with the new guard gem: [guard-rails-assets](https://github.com/dnagir/guard-rails-assets). It works well for me and should be a pretty good start.
johnbintz commented 2011-06-17 13:44:36 +00:00 (Migrated from github.com)
Copy Link

Sweet, I'll give it a shot this weekend and will mention it in the docs when you declare it ready to go. :)

Sweet, I'll give it a shot this weekend and will mention it in the docs when you declare it ready to go. :)
dnagir commented 2011-06-17 14:51:18 +00:00 (Migrated from github.com)
Copy Link

I have been using it for a couple of weeks now.
Let me know if it works well for you. Then we'll declare it ready.:)

I have been using it for a couple of weeks now. Let me know if it works well for you. Then we'll declare it ready.:)
christiannelson commented 2011-06-17 23:15:00 +00:00 (Migrated from github.com)
Copy Link

Just dropped guard-rails-assets in and it's working nicely. Thanks @dnagir! It's slow (silly rails startup), but still useful.

Just dropped guard-rails-assets in and it's working nicely. Thanks @dnagir! It's slow (silly rails startup), but still useful.
johnbintz commented 2011-06-18 13:37:52 +00:00 (Migrated from github.com)
Copy Link

Awesome, I'll update the docs on all the projects. Thanks for all your help!

Awesome, I'll update the docs on all the projects. Thanks for all your help!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
bug

   
doc

   
feature
No Label
bug
doc
feature
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: github-migration/jasmine-headless-webkit#11
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?