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

[johnbintz]

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]

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]

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]

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]

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":

cc61946

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]

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]

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

[johnbintz]

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]

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:

#11 (comment)

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

[dnagir]

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

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

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]

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]

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

[dnagir]

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

[johnbintz]

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

[dnagir]

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]

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

[johnbintz]

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