Has anyone else been using jasmine in a rails 3.1 project? It seems
really convenient to me to have my jasmine specs served up from the
asset pipeline, this means I can reload a page to run my specs and and
have any dependencies get rebuilt. Particularly as I'm writing all my
code in coffeescript this seems quite handy. Is anyone else already
doing this, or interested? If so, I'll package what I have into a gem
and put it out on the git hubs.
> Has anyone else been using jasmine in a rails 3.1 project? It seems
> really convenient to me to have my jasmine specs served up from the
> asset pipeline, this means I can reload a page to run my specs and and
> have any dependencies get rebuilt. Particularly as I'm writing all my
> code in coffeescript this seems quite handy. Is anyone else already
> doing this, or interested? If so, I'll package what I have into a gem
> and put it out on the git hubs.
I have a working example here: git:// github.com/superchris/backbone_coffeescript_demo.git
I added spec/assets/javascripts to the asset pipeline and put the jasmine code in vendor/assets. I then wrote a spec.js.coffee which requires the application code, spec helper and specs (there is only one in this project, but it would grab any others as well). I adapted the SpecRunner.html to reference the code from the right paths and it "just worked". I'd like to take what I have here and package it up so it's easy to get this going on a rails 3.1 project. I'd welcome any help on this.
--Chris
On Sun, Jun 12, 2011 at 11:24 AM, Mike Gehard <mgeh...@pivotallabs.com>wrote:
> I've been thinking about this as well and would like to see what you > have.
> Going to spend some time today looking into this so if you have a > chance to push to github it would be appreciated.
> Mike
> On Jun 11, 7:32 pm, Chris Nelson <superchrisnel...@gmail.com> wrote: > > Has anyone else been using jasmine in a rails 3.1 project? It seems > > really convenient to me to have my jasmine specs served up from the > > asset pipeline, this means I can reload a page to run my specs and and > > have any dependencies get rebuilt. Particularly as I'm writing all my > > code in coffeescript this seems quite handy. Is anyone else already > > doing this, or interested? If so, I'll package what I have into a gem > > and put it out on the git hubs.
> -- > You received this message because you are subscribed to the Google Groups > "Jasmine" group. > To post to this group, send email to jasmine-js@googlegroups.com. > To unsubscribe from this group, send email to > jasmine-js+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jasmine-js?hl=en.
This approach works great for Rails3.1 apps but it's got me thinking
about what to do for non-Rails3.1 apps. Why should they get all of
the fun. :-)
I'm thinking about trying to patch the jasmine-gem to serve up
coffeescript based specs and app files by using rack-coffee (https://
github.com/mattly/rack-coffee) so that you don't need to be running
Rails3.1 to be able to use coffeescript based specs.
Thanks for sharing your app/ideas.
On Jun 12, 10:46 am, Chris Nelson <ch...@gaslightsoftware.com> wrote:
> I have a working example here: git://
> github.com/superchris/backbone_coffeescript_demo.git
> I added spec/assets/javascripts to the asset pipeline and put the jasmine
> code in vendor/assets. I then wrote a spec.js.coffee which requires the
> application code, spec helper and specs (there is only one in this project,
> but it would grab any others as well). I adapted the SpecRunner.html to
> reference the code from the right paths and it "just worked". I'd like to
> take what I have here and package it up so it's easy to get this going on a
> rails 3.1 project. I'd welcome any help on this.
> --Chris
> On Sun, Jun 12, 2011 at 11:24 AM, Mike Gehard <mgeh...@pivotallabs.com>wrote:
> > Chris,
> > I've been thinking about this as well and would like to see what you
> > have.
> > Going to spend some time today looking into this so if you have a
> > chance to push to github it would be appreciated.
> > Mike
> > On Jun 11, 7:32 pm, Chris Nelson <superchrisnel...@gmail.com> wrote:
> > > Has anyone else been using jasmine in a rails 3.1 project? It seems
> > > really convenient to me to have my jasmine specs served up from the
> > > asset pipeline, this means I can reload a page to run my specs and and
> > > have any dependencies get rebuilt. Particularly as I'm writing all my
> > > code in coffeescript this seems quite handy. Is anyone else already
> > > doing this, or interested? If so, I'll package what I have into a gem
> > > and put it out on the git hubs.
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Jasmine" group.
> > To post to this group, send email to jasmine-js@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jasmine-js+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/jasmine-js?hl=en.
Yeah, I'm more focused on how do we let specs integrate into the the asset pipeline right now. There are so many advantages, compiling coffeescript is just one, but managing dependencies and letting us package assets into gems are even more compelling to me. Kinda thinking of putting out what I have as a specific gem: jasmine_rails31 or something.
--Chris
On Sun, Jun 12, 2011 at 4:38 PM, Mike Gehard <mgeh...@pivotallabs.com>wrote:
> This approach works great for Rails3.1 apps but it's got me thinking > about what to do for non-Rails3.1 apps. Why should they get all of > the fun. :-)
> I'm thinking about trying to patch the jasmine-gem to serve up > coffeescript based specs and app files by using rack-coffee (https:// > github.com/mattly/rack-coffee) so that you don't need to be running > Rails3.1 to be able to use coffeescript based specs.
> Thanks for sharing your app/ideas.
> On Jun 12, 10:46 am, Chris Nelson <ch...@gaslightsoftware.com> wrote: > > Hi Mike,
> > I have a working example here: git:// > > github.com/superchris/backbone_coffeescript_demo.git
> > I added spec/assets/javascripts to the asset pipeline and put the jasmine > > code in vendor/assets. I then wrote a spec.js.coffee which requires the > > application code, spec helper and specs (there is only one in this > project, > > but it would grab any others as well). I adapted the SpecRunner.html to > > reference the code from the right paths and it "just worked". I'd like > to > > take what I have here and package it up so it's easy to get this going on > a > > rails 3.1 project. I'd welcome any help on this.
> > --Chris
> > On Sun, Jun 12, 2011 at 11:24 AM, Mike Gehard <mgeh...@pivotallabs.com > >wrote:
> > > Chris,
> > > I've been thinking about this as well and would like to see what you > > > have.
> > > Going to spend some time today looking into this so if you have a > > > chance to push to github it would be appreciated.
> > > Mike
> > > On Jun 11, 7:32 pm, Chris Nelson <superchrisnel...@gmail.com> wrote: > > > > Has anyone else been using jasmine in a rails 3.1 project? It seems > > > > really convenient to me to have my jasmine specs served up from the > > > > asset pipeline, this means I can reload a page to run my specs and > and > > > > have any dependencies get rebuilt. Particularly as I'm writing all > my > > > > code in coffeescript this seems quite handy. Is anyone else already > > > > doing this, or interested? If so, I'll package what I have into a > gem > > > > and put it out on the git hubs.
> > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Jasmine" group. > > > To post to this group, send email to jasmine-js@googlegroups.com. > > > To unsubscribe from this group, send email to > > > jasmine-js+unsubscribe@googlegroups.com. > > > For more options, visit this group at > > >http://groups.google.com/group/jasmine-js?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Jasmine" group. > To post to this group, send email to jasmine-js@googlegroups.com. > To unsubscribe from this group, send email to > jasmine-js+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jasmine-js?hl=en.
I've got jasmin working with the Rails 3.1 and the asset pipeline and it's possible to pull assets into the specs that are gem packaged.
Perhaps if the features are not quite what you need you could use it as a starting point. I only threw it together yesterday after getting frustrated with the current jasmine gem.
I'm reviving this thread after independently playing with Chris's demo
& also Brad's gem.
Has there been any movement on this recently? I'm really interested to
learn what the current options are out there for integrating Jasmine
with Rails. Leveraging the asset pipeline seems like the smartest
thing to do moving forward.
Things I'm interested in figuring out the best approach that gets me
as many of these as possible:
1. Headless execution for CI (worst case, one could write a Cuke that
looks at a spec runner page and looks for green)
2. Dynamic coffee compilation
3. Picks up new assets/files as they're added (preventing a high
maintenance SpecRunner page)
4. SpecRunner individually sources each script as opposed to
concatenating them for easier debugging.
5. RSpec integration would be nifty
Maybe a new gem to address these and other niceties is called for. I
never thought I'd expect my Jasmine workflow on Java projects would
feel tighter than on Rails. I'm suspicious enough of that conclusion
that I'm willing to bet I'm just ignorant of a better way to do it.
Thoughts?
-Justin
On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote:
> I've got jasmin working with the Rails 3.1 and the asset pipeline and it's
> possible
> to pull assets into the specs that are gem packaged.
> Perhaps if the features are not quite what you need you could use it as a
> starting point.
> I only threw it together yesterday after getting frustrated with the current
> jasmine gem.
I think 2 and 3 (and whatever work we need to actually use the pipeline) are probably near-term priorities for the Jasmine gem, but I think you're correct in that it's going to take awhile to get there. We haven't been great about timely acceptance of pull requests (we're trying to get that better), but I'd love to see patches go into jasmine-gem rather than fragmented into another Rails 3.1-only gem.
It's possible we're eventually going to be pushed into splitting up the gem regardless. The original intent of having a single gem that meets many purposes was so people could simply type `gem install jasmine` and get going; as Rails 3.1 changes many things about how JS works and Rails 2 falls farther behind Rails 3 this is getting tricky to keep in place.
On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> wrote: > I'm reviving this thread after independently playing with Chris's demo > & also Brad's gem.
> Has there been any movement on this recently? I'm really interested to > learn what the current options are out there for integrating Jasmine > with Rails. Leveraging the asset pipeline seems like the smartest > thing to do moving forward.
> Things I'm interested in figuring out the best approach that gets me > as many of these as possible:
> 1. Headless execution for CI (worst case, one could write a Cuke that > looks at a spec runner page and looks for green) > 2. Dynamic coffee compilation > 3. Picks up new assets/files as they're added (preventing a high > maintenance SpecRunner page) > 4. SpecRunner individually sources each script as opposed to > concatenating them for easier debugging. > 5. RSpec integration would be nifty
> I doubt the official jasmine gem is immediately headed in this > direction. The asset pipeline represents such a major break from the > past that it would be difficult to maintain BC. (related:
> Maybe a new gem to address these and other niceties is called for. I > never thought I'd expect my Jasmine workflow on Java projects would > feel tighter than on Rails. I'm suspicious enough of that conclusion > that I'm willing to bet I'm just ignorant of a better way to do it.
> Thoughts?
> -Justin
> On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote: > > Hi Chris,
> > I've put a gem together that I think partially solves what you need.
> > I've got jasmin working with the Rails 3.1 and the asset pipeline and > it's > > possible > > to pull assets into the specs that are gem packaged.
> > Perhaps if the features are not quite what you need you could use it as a > > starting point. > > I only threw it together yesterday after getting frustrated with the > current > > jasmine gem.
> > Regards
> > Brad
> -- > You received this message because you are subscribed to the Google Groups > "Jasmine" group. > To post to this group, send email to jasmine-js@googlegroups.com. > To unsubscribe from this group, send email to > jasmine-js+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jasmine-js?hl=en.
In the meantime I had a pretty good experience with jasmine-headless-
webkit last week. I'm looking at adding a simple custom spec runner
ERB template that loads in the same stuff the jasmine.yml calls for so
you can also load the specs in browser when you want to. (Not to work
around or circumvent your great work, Rajan; just in the interest in
getting a good working solution for 3.1 today).
> I think 2 and 3 (and whatever work we need to actually use the pipeline) are
> probably near-term priorities for the Jasmine gem, but I think you're
> correct in that it's going to take awhile to get there. We haven't been
> great about timely acceptance of pull requests (we're trying to get that
> better), but I'd love to see patches go into jasmine-gem rather than
> fragmented into another Rails 3.1-only gem.
> It's possible we're eventually going to be pushed into splitting up the gem
> regardless. The original intent of having a single gem that meets many
> purposes was so people could simply type `gem install jasmine` and get
> going; as Rails 3.1 changes many things about how JS works and Rails 2 falls
> farther behind Rails 3 this is getting tricky to keep in place.
> On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> wrote:
> > I'm reviving this thread after independently playing with Chris's demo
> > & also Brad's gem.
> > Has there been any movement on this recently? I'm really interested to
> > learn what the current options are out there for integrating Jasmine
> > with Rails. Leveraging the asset pipeline seems like the smartest
> > thing to do moving forward.
> > Things I'm interested in figuring out the best approach that gets me
> > as many of these as possible:
> > 1. Headless execution for CI (worst case, one could write a Cuke that
> > looks at a spec runner page and looks for green)
> > 2. Dynamic coffee compilation
> > 3. Picks up new assets/files as they're added (preventing a high
> > maintenance SpecRunner page)
> > 4. SpecRunner individually sources each script as opposed to
> > concatenating them for easier debugging.
> > 5. RSpec integration would be nifty
> > I doubt the official jasmine gem is immediately headed in this
> > direction. The asset pipeline represents such a major break from the
> > past that it would be difficult to maintain BC. (related:
> > Maybe a new gem to address these and other niceties is called for. I
> > never thought I'd expect my Jasmine workflow on Java projects would
> > feel tighter than on Rails. I'm suspicious enough of that conclusion
> > that I'm willing to bet I'm just ignorant of a better way to do it.
> > Thoughts?
> > -Justin
> > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote:
> > > Hi Chris,
> > > I've put a gem together that I think partially solves what you need.
> > > I've got jasmin working with the Rails 3.1 and the asset pipeline and
> > it's
> > > possible
> > > to pull assets into the specs that are gem packaged.
> > > Perhaps if the features are not quite what you need you could use it as a
> > > starting point.
> > > I only threw it together yesterday after getting frustrated with the
> > current
> > > jasmine gem.
> > > Regards
> > > Brad
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Jasmine" group.
> > To post to this group, send email to jasmine-js@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jasmine-js+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/jasmine-js?hl=en.
Awesome! We are gearing up to take on the challenges of working with 3.1 and stuff like RequireJS, so these sorts of things will be great examples for us to follow. I am hoping we have a solution for Rails 3.1 folks before it gets officially released.
On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> wrote: > In the meantime I had a pretty good experience with jasmine-headless- > webkit last week. I'm looking at adding a simple custom spec runner > ERB template that loads in the same stuff the jasmine.yml calls for so > you can also load the specs in browser when you want to. (Not to work > around or circumvent your great work, Rajan; just in the interest in > getting a good working solution for 3.1 today).
> On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > I think 2 and 3 (and whatever work we need to actually use the pipeline) > are > > probably near-term priorities for the Jasmine gem, but I think you're > > correct in that it's going to take awhile to get there. We haven't been > > great about timely acceptance of pull requests (we're trying to get that > > better), but I'd love to see patches go into jasmine-gem rather than > > fragmented into another Rails 3.1-only gem.
> > It's possible we're eventually going to be pushed into splitting up the > gem > > regardless. The original intent of having a single gem that meets many > > purposes was so people could simply type `gem install jasmine` and get > > going; as Rails 3.1 changes many things about how JS works and Rails 2 > falls > > farther behind Rails 3 this is getting tricky to keep in place.
> > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> wrote: > > > I'm reviving this thread after independently playing with Chris's demo > > > & also Brad's gem.
> > > Has there been any movement on this recently? I'm really interested to > > > learn what the current options are out there for integrating Jasmine > > > with Rails. Leveraging the asset pipeline seems like the smartest > > > thing to do moving forward.
> > > Things I'm interested in figuring out the best approach that gets me > > > as many of these as possible:
> > > 1. Headless execution for CI (worst case, one could write a Cuke that > > > looks at a spec runner page and looks for green) > > > 2. Dynamic coffee compilation > > > 3. Picks up new assets/files as they're added (preventing a high > > > maintenance SpecRunner page) > > > 4. SpecRunner individually sources each script as opposed to > > > concatenating them for easier debugging. > > > 5. RSpec integration would be nifty
> > > I doubt the official jasmine gem is immediately headed in this > > > direction. The asset pipeline represents such a major break from the > > > past that it would be difficult to maintain BC. (related:
> > > Maybe a new gem to address these and other niceties is called for. I > > > never thought I'd expect my Jasmine workflow on Java projects would > > > feel tighter than on Rails. I'm suspicious enough of that conclusion > > > that I'm willing to bet I'm just ignorant of a better way to do it.
> > > Thoughts?
> > > -Justin
> > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote: > > > > Hi Chris,
> > > > I've put a gem together that I think partially solves what you need.
> > > > I've got jasmin working with the Rails 3.1 and the asset pipeline and > > > it's > > > > possible > > > > to pull assets into the specs that are gem packaged.
> > > > Perhaps if the features are not quite what you need you could use it > as a > > > > starting point. > > > > I only threw it together yesterday after getting frustrated with the > > > current > > > > jasmine gem.
> > > > Regards
> > > > Brad
> > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "Jasmine" group. > > > To post to this group, send email to jasmine-js@googlegroups.com. > > > To unsubscribe from this group, send email to > > > jasmine-js+unsubscribe@googlegroups.com. > > > For more options, visit this group at > > >http://groups.google.com/group/jasmine-js?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Jasmine" group. > To post to this group, send email to jasmine-js@googlegroups.com. > To unsubscribe from this group, send email to > jasmine-js+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/jasmine-js?hl=en.
> Awesome! We are gearing up to take on the challenges of working with 3.1 and
> stuff like RequireJS, so these sorts of things will be great examples for us
> to follow. I am hoping we have a solution for Rails 3.1 folks before it gets
> officially released.
> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> wrote:
> > In the meantime I had a pretty good experience with jasmine-headless-
> > webkit last week. I'm looking at adding a simple custom spec runner
> > ERB template that loads in the same stuff the jasmine.yml calls for so
> > you can also load the specs in browser when you want to. (Not to work
> > around or circumvent your great work, Rajan; just in the interest in
> > getting a good working solution for 3.1 today).
> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> > > I think 2 and 3 (and whatever work we need to actually use the pipeline)
> > are
> > > probably near-term priorities for the Jasmine gem, but I think you're
> > > correct in that it's going to take awhile to get there. We haven't been
> > > great about timely acceptance of pull requests (we're trying to get that
> > > better), but I'd love to see patches go into jasmine-gem rather than
> > > fragmented into another Rails 3.1-only gem.
> > > It's possible we're eventually going to be pushed into splitting up the
> > gem
> > > regardless. The original intent of having a single gem that meets many
> > > purposes was so people could simply type `gem install jasmine` and get
> > > going; as Rails 3.1 changes many things about how JS works and Rails 2
> > falls
> > > farther behind Rails 3 this is getting tricky to keep in place.
> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> wrote:
> > > > I'm reviving this thread after independently playing with Chris's demo
> > > > & also Brad's gem.
> > > > Has there been any movement on this recently? I'm really interested to
> > > > learn what the current options are out there for integrating Jasmine
> > > > with Rails. Leveraging the asset pipeline seems like the smartest
> > > > thing to do moving forward.
> > > > Things I'm interested in figuring out the best approach that gets me
> > > > as many of these as possible:
> > > > 1. Headless execution for CI (worst case, one could write a Cuke that
> > > > looks at a spec runner page and looks for green)
> > > > 2. Dynamic coffee compilation
> > > > 3. Picks up new assets/files as they're added (preventing a high
> > > > maintenance SpecRunner page)
> > > > 4. SpecRunner individually sources each script as opposed to
> > > > concatenating them for easier debugging.
> > > > 5. RSpec integration would be nifty
> > > > I doubt the official jasmine gem is immediately headed in this
> > > > direction. The asset pipeline represents such a major break from the
> > > > past that it would be difficult to maintain BC. (related:
> > > > Maybe a new gem to address these and other niceties is called for. I
> > > > never thought I'd expect my Jasmine workflow on Java projects would
> > > > feel tighter than on Rails. I'm suspicious enough of that conclusion
> > > > that I'm willing to bet I'm just ignorant of a better way to do it.
> > > > Thoughts?
> > > > -Justin
> > > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote:
> > > > > Hi Chris,
> > > > > I've put a gem together that I think partially solves what you need.
> > > > > I've got jasmin working with the Rails 3.1 and the asset pipeline and
> > > > it's
> > > > > possible
> > > > > to pull assets into the specs that are gem packaged.
> > > > > Perhaps if the features are not quite what you need you could use it
> > as a
> > > > > starting point.
> > > > > I only threw it together yesterday after getting frustrated with the
> > > > current
> > > > > jasmine gem.
> > > > > Regards
> > > > > Brad
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Jasmine" group.
> > > > To post to this group, send email to jasmine-js@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > jasmine-js+unsubscribe@googlegroups.com.
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/jasmine-js?hl=en.
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Jasmine" group.
> > To post to this group, send email to jasmine-js@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jasmine-js+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/jasmine-js?hl=en.
I spent a few hours this morning adding extremely basic asset pipeline support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem (http://github.com/pivotal/jasmine-gem).
Essentially the jasmine.yml file now takes asset_pipeline_paths, each path you pass here will be mapped through the Sprockets asset pipeline. We have a bit of a 'hack' in order to permit running files in the spec directory through Sprockets -- if one of your asset_pipeline_paths matches your spec_dir, we'll assume you want to use Sprockets for specs (there's a long story about why the spec dir gets mapped as __spec__ inside of relative to root, something we might re-examine in Jasmine 2).
Files passed in will now have any Sprocket compatible engine extensions stripped off so that we correctly request them from Sprockets -- ie, app/assets/my_file.js.coffee will be requested by Jasmine as /app/assets/my_file.js.
I believe Jasmine should do the right thing if you hand it scss files in your stylesheets and coffee files in your helpers, but I haven't yet tested it.
This is a pretty minimal spike, so there may be other issues; hoping this meets the 80% case for most people -- please feel free to offer your feedback!
Thanks!
Rajan
PS: Here's a sample configuration file to use coffeescript for your src and specs:
# src_files # # Return an array of filepaths relative to src_dir to include before jasmine specs. # Default: [] # # EXAMPLE: # # src_files: # - lib/source1.js # - lib/source2.js # - dist/**/*.js # src_files: - "app/assets/**/*.coffee" # stylesheets # # Return an array of stylesheet filepaths relative to src_dir to include before jasmine specs. # Default: [] # # EXAMPLE: # # stylesheets: # - css/style.css # - stylesheets/*.css # stylesheets: - stylesheets/**/*.css
# helpers # # Return an array of filepaths relative to spec_dir to include before jasmine specs. # Default: ["helpers/**/*.js"] # # EXAMPLE: # # helpers: # - helpers/**/*.js # helpers: - helpers/**/*.js
# spec_files # # Return an array of filepaths relative to spec_dir to include. # Default: ["**/*[sS]pec.js"] # # EXAMPLE: # # spec_files: # - **/*[sS]pec.js # spec_files: - '**/*[sS]pec.js.coffee'
# src_dir # # Source directory path. Your src_files must be returned relative to this path. Will use root if left blank. # Default: project root # # EXAMPLE: # # src_dir: public # src_dir:
# spec_dir # # Spec directory path. Your spec_files must be returned relative to this path. # Default: spec/javascripts # # EXAMPLE: # # spec_dir: spec/javascripts # spec_dir: spec/javascripts
# asset_pipeline_paths # # Paths you would like to be served by the Sprockets asset pipeline. # # If you include your spec_dir (eg: - spec/javascripts ) here, # Jasmine will use the Sprockets asset pipeline to build your spec files. # # Default: [] # # EXAMPLE: # asset_pipeline_paths: # - app/assets # - spec/javascripts asset_pipeline_paths: - app/assets - spec/javascripts
On Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> wrote: >> We are gearing up to take on the challenges of working with 3.1 and >> stuff like RequireJS
> Sounds great, I'd definitely be interested in trying out/using this > functionality when it exists.
> Thanks,
> Colin
> On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: >> Awesome! We are gearing up to take on the challenges of working with 3.1 and >> stuff like RequireJS, so these sorts of things will be great examples for us >> to follow. I am hoping we have a solution for Rails 3.1 folks before it gets >> officially released.
>> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> wrote: >> > In the meantime I had a pretty good experience with jasmine-headless- >> > webkit last week. I'm looking at adding a simple custom spec runner >> > ERB template that loads in the same stuff the jasmine.yml calls for so >> > you can also load the specs in browser when you want to. (Not to work >> > around or circumvent your great work, Rajan; just in the interest in >> > getting a good working solution for 3.1 today).
>> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: >> > > I think 2 and 3 (and whatever work we need to actually use the pipeline) >> > are >> > > probably near-term priorities for the Jasmine gem, but I think you're >> > > correct in that it's going to take awhile to get there. We haven't been >> > > great about timely acceptance of pull requests (we're trying to get that >> > > better), but I'd love to see patches go into jasmine-gem rather than >> > > fragmented into another Rails 3.1-only gem.
>> > > It's possible we're eventually going to be pushed into splitting up the >> > gem >> > > regardless. The original intent of having a single gem that meets many >> > > purposes was so people could simply type `gem install jasmine` and get >> > > going; as Rails 3.1 changes many things about how JS works and Rails 2 >> > falls >> > > farther behind Rails 3 this is getting tricky to keep in place.
>> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> wrote: >> > > > I'm reviving this thread after independently playing with Chris's demo >> > > > & also Brad's gem.
>> > > > Has there been any movement on this recently? I'm really interested to >> > > > learn what the current options are out there for integrating Jasmine >> > > > with Rails. Leveraging the asset pipeline seems like the smartest >> > > > thing to do moving forward.
>> > > > Things I'm interested in figuring out the best approach that gets me >> > > > as many of these as possible:
>> > > > 1. Headless execution for CI (worst case, one could write a Cuke that >> > > > looks at a spec runner page and looks for green) >> > > > 2. Dynamic coffee compilation >> > > > 3. Picks up new assets/files as they're added (preventing a high >> > > > maintenance SpecRunner page) >> > > > 4. SpecRunner individually sources each script as opposed to >> > > > concatenating them for easier debugging. >> > > > 5. RSpec integration would be nifty
>> > > > I doubt the official jasmine gem is immediately headed in this >> > > > direction. The asset pipeline represents such a major break from the >> > > > past that it would be difficult to maintain BC. (related:
>> > > > Maybe a new gem to address these and other niceties is called for. I >> > > > never thought I'd expect my Jasmine workflow on Java projects would >> > > > feel tighter than on Rails. I'm suspicious enough of that conclusion >> > > > that I'm willing to bet I'm just ignorant of a better way to do it.
>> > > > Thoughts?
>> > > > -Justin
>> > > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote: >> > > > > Hi Chris,
>> > > > > I've put a gem together that I think partially solves what you need.
>> > > > > I've got jasmin working with the Rails 3.1 and the asset pipeline and >> > > > it's >> > > > > possible >> > > > > to pull assets into the specs that are gem packaged.
>> > > > > Perhaps if the features are not quite what you need you could use it >> > as a >> > > > > starting point. >> > > > > I only threw it together yesterday after getting frustrated with the >> > > > current >> > > > > jasmine gem.
>> > > > > Regards
>> > > > > Brad
>> > > > -- >> > > > You received this message because you are subscribed to the Google >> > Groups >> > > > "Jasmine" group. >> > > > To post to this group, send email to jasmine-js@googlegroups.com. >> > > > To unsubscribe from this group, send email to >> > > > jasmine-js+unsubscribe@googlegroups.com. >> > > > For more options, visit this group at >> > > >http://groups.google.com/group/jasmine-js?hl=en.
>> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Jasmine" group. >> > To post to this group, send email to jasmine-js@googlegroups.com. >> > To unsubscribe from this group, send email to >> > jasmine-js+unsubscribe@googlegroups.com. >> > For more options, visit this group at >> >http://groups.google.com/group/jasmine-js?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Jasmine" group. > To post to this group, send email to jasmine-js@googlegroups.com. > To unsubscribe from this group, send email to jasmine-js+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/jasmine-js?hl=en.
I should note that this update doesn't yet support loading jquery from the assets path because the file doesn't exist on the local filesystem -- for now it'll need to be loaded from helpers, I suppose.
On Sat, Sep 10, 2011 at 1:37 PM, Rajan Agaskar <ra...@pivotallabs.com>wrote:
> I spent a few hours this morning adding extremely basic asset pipeline > support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem > (http://github.com/pivotal/jasmine-gem).
> Essentially the jasmine.yml file now takes asset_pipeline_paths, each > path you pass here will be mapped through the Sprockets asset > pipeline. We have a bit of a 'hack' in order to permit running files > in the spec directory through Sprockets -- if one of your > asset_pipeline_paths matches your spec_dir, we'll assume you want to > use Sprockets for specs (there's a long story about why the spec dir > gets mapped as __spec__ inside of relative to root, something we might > re-examine in Jasmine 2).
> Files passed in will now have any Sprocket compatible engine > extensions stripped off so that we correctly request them from > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by > Jasmine as /app/assets/my_file.js.
> I believe Jasmine should do the right thing if you hand it scss files > in your stylesheets and coffee files in your helpers, but I haven't > yet tested it.
> This is a pretty minimal spike, so there may be other issues; hoping > this meets the 80% case for most people -- please feel free to offer > your feedback!
> Thanks!
> Rajan
> PS: > Here's a sample configuration file to use coffeescript for your src and > specs:
> # src_files > # > # Return an array of filepaths relative to src_dir to include before > jasmine specs. > # Default: [] > # > # EXAMPLE: > # > # src_files: > # - lib/source1.js > # - lib/source2.js > # - dist/**/*.js > # > src_files: > - "app/assets/**/*.coffee" > # stylesheets > # > # Return an array of stylesheet filepaths relative to src_dir to > include before jasmine specs. > # Default: [] > # > # EXAMPLE: > # > # stylesheets: > # - css/style.css > # - stylesheets/*.css > # > stylesheets: > - stylesheets/**/*.css
> # helpers > # > # Return an array of filepaths relative to spec_dir to include before > jasmine specs. > # Default: ["helpers/**/*.js"] > # > # EXAMPLE: > # > # helpers: > # - helpers/**/*.js > # > helpers: > - helpers/**/*.js
> # src_dir > # > # Source directory path. Your src_files must be returned relative to > this path. Will use root if left blank. > # Default: project root > # > # EXAMPLE: > # > # src_dir: public > # > src_dir:
> # spec_dir > # > # Spec directory path. Your spec_files must be returned relative to this > path. > # Default: spec/javascripts > # > # EXAMPLE: > # > # spec_dir: spec/javascripts > # > spec_dir: spec/javascripts
> # asset_pipeline_paths > # > # Paths you would like to be served by the Sprockets asset pipeline. > # > # If you include your spec_dir (eg: - spec/javascripts ) here, > # Jasmine will use the Sprockets asset pipeline to build your spec files. > # > # Default: [] > # > # EXAMPLE: > # asset_pipeline_paths: > # - app/assets > # - spec/javascripts > asset_pipeline_paths: > - app/assets > - spec/javascripts
> On Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> wrote: > >> We are gearing up to take on the challenges of working with 3.1 and > >> stuff like RequireJS
> > Sounds great, I'd definitely be interested in trying out/using this > > functionality when it exists.
> > Thanks,
> > Colin
> > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: > >> Awesome! We are gearing up to take on the challenges of working with 3.1 > and > >> stuff like RequireJS, so these sorts of things will be great examples > for us > >> to follow. I am hoping we have a solution for Rails 3.1 folks before it > gets > >> officially released.
> >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> > wrote: > >> > In the meantime I had a pretty good experience with jasmine-headless- > >> > webkit last week. I'm looking at adding a simple custom spec runner > >> > ERB template that loads in the same stuff the jasmine.yml calls for so > >> > you can also load the specs in browser when you want to. (Not to work > >> > around or circumvent your great work, Rajan; just in the interest in > >> > getting a good working solution for 3.1 today).
> >> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: > >> > > I think 2 and 3 (and whatever work we need to actually use the > pipeline) > >> > are > >> > > probably near-term priorities for the Jasmine gem, but I think > you're > >> > > correct in that it's going to take awhile to get there. We haven't > been > >> > > great about timely acceptance of pull requests (we're trying to get > that > >> > > better), but I'd love to see patches go into jasmine-gem rather than > >> > > fragmented into another Rails 3.1-only gem.
> >> > > It's possible we're eventually going to be pushed into splitting up > the > >> > gem > >> > > regardless. The original intent of having a single gem that meets > many > >> > > purposes was so people could simply type `gem install jasmine` and > get > >> > > going; as Rails 3.1 changes many things about how JS works and Rails > 2 > >> > falls > >> > > farther behind Rails 3 this is getting tricky to keep in place.
> >> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> > wrote: > >> > > > I'm reviving this thread after independently playing with Chris's > demo > >> > > > & also Brad's gem.
> >> > > > Has there been any movement on this recently? I'm really > interested to > >> > > > learn what the current options are out there for integrating > Jasmine > >> > > > with Rails. Leveraging the asset pipeline seems like the smartest > >> > > > thing to do moving forward.
> >> > > > Things I'm interested in figuring out the best approach that gets > me > >> > > > as many of these as possible:
> >> > > > 1. Headless execution for CI (worst case, one could write a Cuke > that > >> > > > looks at a spec runner page and looks for green) > >> > > > 2. Dynamic coffee compilation > >> > > > 3. Picks up new assets/files as they're added (preventing a high > >> > > > maintenance SpecRunner page) > >> > > > 4. SpecRunner individually sources each script as opposed to > >> > > > concatenating them for easier debugging. > >> > > > 5. RSpec integration would be nifty
> >> > > > I doubt the official jasmine gem is immediately headed in this > >> > > > direction. The asset pipeline represents such a major break from > the > >> > > > past that it would be difficult to maintain BC. (related:
> >> > > > Maybe a new gem to address these and other niceties is called for. > I > >> > > > never thought I'd expect my Jasmine workflow on Java projects > would > >> > > > feel tighter than on Rails. I'm suspicious enough of that > conclusion > >> > > > that I'm willing to bet I'm just ignorant of a better way to do > it.
> >> > > > Thoughts?
> >> > > > -Justin
> >> > > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote: > >> > > > > Hi Chris,
> >> > > > > I've put a gem together that I think partially solves what you > need.
> >> > > > > I've got jasmin working with the Rails 3.1 and the asset > pipeline and > >> > > > it's > >> > > > > possible > >> > > > > to pull assets into the specs that are gem packaged.
> >> > > > > Perhaps if the features are not quite what you need you could > use it > >> > as a > >> > > > > starting point. > >> > > > > I only threw it together yesterday after getting frustrated with > the > >> > > > current > >> > > > > jasmine gem.
> >> > > > > Regards
> >> > > > > Brad
> >> > > > -- > >> > > > You received this message because you are subscribed to the Google > >> > Groups > >> > > > "Jasmine" group. > >> > > > To post to this group, send email to jasmine-js@googlegroups.com. > >> > > > To unsubscribe from this group, send email to > >> > > > jasmine-js+unsubscribe@googlegroups.com. > >> > > > For more options, visit this group at > >> > > >http://groups.google.com/group/jasmine-js?hl=en.
> >> > -- > >> > You received this message because you are subscribed to the Google > Groups > >> > "Jasmine" group. > >> > To post to this group, send email to jasmine-js@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > jasmine-js+unsubscribe@googlegroups.com. > >> > For more options, visit this group at > >> >http://groups.google.com/group/jasmine-js?hl=en.
> > -- > > You received this message because you are subscribed to the Google Groups > "Jasmine" group. > > To post to this group, send email to jasmine-js@googlegroups.com. > > To unsubscribe from this group, send email to > jasmine-js+unsubscribe@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/jasmine-js?hl=en.
Can you sketch out a little how to 'load jQuery from helpers'? I'm
hesitant to seek to discover this issue where I employ jQuery in my
specs, before maybe someone can indicate the trick.
(BTW - this is all very timely. To me, it has felt like UI behavior
coding was always an afterthought, if at all, in Rails land. Now, with
Node.js, the distinction is beginning to lose practical meaning, but
it'd be nice to see Rails catch up where it can.)
Lille
On Sep 10, 2:21 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> I should note that this update doesn't yet support loading jquery from the
> assets path because the file doesn't exist on the local filesystem -- for
> now it'll need to be loaded from helpers, I suppose.
> On Sat, Sep 10, 2011 at 1:37 PM, Rajan Agaskar <ra...@pivotallabs.com>wrote:
> > I spent a few hours this morning adding extremely basic asset pipeline
> > support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem
> > (http://github.com/pivotal/jasmine-gem).
> > Essentially the jasmine.yml file now takes asset_pipeline_paths, each
> > path you pass here will be mapped through the Sprockets asset
> > pipeline. We have a bit of a 'hack' in order to permit running files
> > in the spec directory through Sprockets -- if one of your
> > asset_pipeline_paths matches your spec_dir, we'll assume you want to
> > use Sprockets for specs (there's a long story about why the spec dir
> > gets mapped as __spec__ inside of relative to root, something we might
> > re-examine in Jasmine 2).
> > Files passed in will now have any Sprocket compatible engine
> > extensions stripped off so that we correctly request them from
> > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by
> > Jasmine as /app/assets/my_file.js.
> > I believe Jasmine should do the right thing if you hand it scss files
> > in your stylesheets and coffee files in your helpers, but I haven't
> > yet tested it.
> > This is a pretty minimal spike, so there may be other issues; hoping
> > this meets the 80% case for most people -- please feel free to offer
> > your feedback!
> > Thanks!
> > Rajan
> > PS:
> > Here's a sample configuration file to use coffeescript for your src and
> > specs:
> > # src_dir
> > #
> > # Source directory path. Your src_files must be returned relative to
> > this path. Will use root if left blank.
> > # Default: project root
> > #
> > # EXAMPLE:
> > #
> > # src_dir: public
> > #
> > src_dir:
> > # spec_dir
> > #
> > # Spec directory path. Your spec_files must be returned relative to this
> > path.
> > # Default: spec/javascripts
> > #
> > # EXAMPLE:
> > #
> > # spec_dir: spec/javascripts
> > #
> > spec_dir: spec/javascripts
> > # asset_pipeline_paths
> > #
> > # Paths you would like to be served by the Sprockets asset pipeline.
> > #
> > # If you include your spec_dir (eg: - spec/javascripts ) here,
> > # Jasmine will use the Sprockets asset pipeline to build your spec files.
> > #
> > # Default: []
> > #
> > # EXAMPLE:
> > # asset_pipeline_paths:
> > # - app/assets
> > # - spec/javascripts
> > asset_pipeline_paths:
> > - app/assets
> > - spec/javascripts
> > On Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> wrote:
> > >> We are gearing up to take on the challenges of working with 3.1 and
> > >> stuff like RequireJS
> > > Sounds great, I'd definitely be interested in trying out/using this
> > > functionality when it exists.
> > > Thanks,
> > > Colin
> > > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> > >> Awesome! We are gearing up to take on the challenges of working with 3.1
> > and
> > >> stuff like RequireJS, so these sorts of things will be great examples
> > for us
> > >> to follow. I am hoping we have a solution for Rails 3.1 folks before it
> > gets
> > >> officially released.
> > >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com>
> > wrote:
> > >> > In the meantime I had a pretty good experience with jasmine-headless-
> > >> > webkit last week. I'm looking at adding a simple custom spec runner
> > >> > ERB template that loads in the same stuff the jasmine.yml calls for so
> > >> > you can also load the specs in browser when you want to. (Not to work
> > >> > around or circumvent your great work, Rajan; just in the interest in
> > >> > getting a good working solution for 3.1 today).
> > >> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> > >> > > I think 2 and 3 (and whatever work we need to actually use the
> > pipeline)
> > >> > are
> > >> > > probably near-term priorities for the Jasmine gem, but I think
> > you're
> > >> > > correct in that it's going to take awhile to get there. We haven't
> > been
> > >> > > great about timely acceptance of pull requests (we're trying to get
> > that
> > >> > > better), but I'd love to see patches go into jasmine-gem rather than
> > >> > > fragmented into another Rails 3.1-only gem.
> > >> > > It's possible we're eventually going to be pushed into splitting up
> > the
> > >> > gem
> > >> > > regardless. The original intent of having a single gem that meets
> > many
> > >> > > purposes was so people could simply type `gem install jasmine` and
> > get
> > >> > > going; as Rails 3.1 changes many things about how JS works and Rails
> > 2
> > >> > falls
> > >> > > farther behind Rails 3 this is getting tricky to keep in place.
> > >> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com>
> > wrote:
> > >> > > > I'm reviving this thread after independently playing with Chris's
> > demo
> > >> > > > & also Brad's gem.
> > >> > > > Has there been any movement on this recently? I'm really
> > interested to
> > >> > > > learn what the current options are out there for integrating
> > Jasmine
> > >> > > > with Rails. Leveraging the asset pipeline seems like the smartest
> > >> > > > thing to do moving forward.
> > >> > > > Things I'm interested in figuring out the best approach that gets
> > me
> > >> > > > as many of these as possible:
> > >> > > > 1. Headless execution for CI (worst case, one could write a Cuke
> > that
> > >> > > > looks at a spec runner page and looks for green)
> > >> > > > 2. Dynamic coffee compilation
> > >> > > > 3. Picks up new assets/files as they're added (preventing a high
> > >> > > > maintenance SpecRunner page)
> > >> > > > 4. SpecRunner individually sources each script as opposed to
> > >> > > > concatenating them for easier debugging.
> > >> > > > 5. RSpec integration would be nifty
> > >> > > > I doubt the official jasmine gem is immediately headed in this
> > >> > > > direction. The asset pipeline represents such a major break from
> > the
> > >> > > > past that it would be difficult to maintain BC. (related:
> > >> > > > Maybe a new gem to address these and other niceties is called for.
> > I
> > >> > > > never thought I'd expect my Jasmine workflow on Java projects
> > would
> > >> > > > feel tighter than on Rails. I'm suspicious enough of that
> > conclusion
> > >> > > > that I'm willing to bet I'm just ignorant of a better way to do
> > it.
> > >> > > > Thoughts?
> > >> > > > -Justin
> > >> > > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote:
> > >> > > > > Hi Chris,
> > >> > > > > I've put a gem together that I think partially solves what you
> > need.
> > >> > > > > I've got jasmin working with the Rails 3.1 and the asset
> > pipeline and
> > >> > > > it's
> > >> > > > > possible
> > >> > > > > to pull assets into the specs that are gem packaged.
> > >> > > > > Perhaps if the features are not quite what you need you could
> > use it
> > >> > as a
> > >> > > > > starting point.
> > >> > > > > I only threw it together yesterday after getting frustrated with
> > the
> > >> > > > current
> > >> > > > > jasmine gem.
> > >> > > > > Regards
> > >> > > > > Brad
> > >> > > > --
> > >> > > > You received this message because you are subscribed to the Google
> > >> > Groups
> > >> > > > "Jasmine" group.
> > >> > > > To post to this group, send email to jasmine-js@googlegroups.com.
> > >> > > > To unsubscribe from this group, send email to
> > >> > > > jasmine-js+unsubscribe@googlegroups.com.
> > >> > > > For more options,
By default Jasmine will load files you place in spec/javascripts/helpers. You'll want to put the version of jquery that Rails provides (and jquery-ui, if you're using it) in there in order for Jasmine to be able to load it for your tests. Rails normally provides these to the asset pipeline via the jquery-rails gem, which jasmine doesn't yet interact with.
On Sat, Sep 17, 2011 at 4:43 PM, Lille <lille.pengu...@gmail.com> wrote: > Rajan,
> Can you sketch out a little how to 'load jQuery from helpers'? I'm > hesitant to seek to discover this issue where I employ jQuery in my > specs, before maybe someone can indicate the trick.
> (BTW - this is all very timely. To me, it has felt like UI behavior > coding was always an afterthought, if at all, in Rails land. Now, with > Node.js, the distinction is beginning to lose practical meaning, but > it'd be nice to see Rails catch up where it can.)
> Lille
> On Sep 10, 2:21 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > I should note that this update doesn't yet support loading jquery from > the > > assets path because the file doesn't exist on the local filesystem -- for > > now it'll need to be loaded from helpers, I suppose.
> > On Sat, Sep 10, 2011 at 1:37 PM, Rajan Agaskar <ra...@pivotallabs.com > >wrote:
> > > I spent a few hours this morning adding extremely basic asset pipeline > > > support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem > > > (http://github.com/pivotal/jasmine-gem).
> > > Essentially the jasmine.yml file now takes asset_pipeline_paths, each > > > path you pass here will be mapped through the Sprockets asset > > > pipeline. We have a bit of a 'hack' in order to permit running files > > > in the spec directory through Sprockets -- if one of your > > > asset_pipeline_paths matches your spec_dir, we'll assume you want to > > > use Sprockets for specs (there's a long story about why the spec dir > > > gets mapped as __spec__ inside of relative to root, something we might > > > re-examine in Jasmine 2).
> > > Files passed in will now have any Sprocket compatible engine > > > extensions stripped off so that we correctly request them from > > > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by > > > Jasmine as /app/assets/my_file.js.
> > > I believe Jasmine should do the right thing if you hand it scss files > > > in your stylesheets and coffee files in your helpers, but I haven't > > > yet tested it.
> > > This is a pretty minimal spike, so there may be other issues; hoping > > > this meets the 80% case for most people -- please feel free to offer > > > your feedback!
> > > Thanks!
> > > Rajan
> > > PS: > > > Here's a sample configuration file to use coffeescript for your src and > > > specs:
> > > # asset_pipeline_paths > > > # > > > # Paths you would like to be served by the Sprockets asset pipeline. > > > # > > > # If you include your spec_dir (eg: - spec/javascripts ) here, > > > # Jasmine will use the Sprockets asset pipeline to build your spec > files. > > > # > > > # Default: [] > > > # > > > # EXAMPLE: > > > # asset_pipeline_paths: > > > # - app/assets > > > # - spec/javascripts > > > asset_pipeline_paths: > > > - app/assets > > > - spec/javascripts
> > > On Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> > wrote: > > > >> We are gearing up to take on the challenges of working with 3.1 and > > > >> stuff like RequireJS
> > > > Sounds great, I'd definitely be interested in trying out/using this > > > > functionality when it exists.
> > > > Thanks,
> > > > Colin
> > > > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > > >> Awesome! We are gearing up to take on the challenges of working with > 3.1 > > > and > > > >> stuff like RequireJS, so these sorts of things will be great > examples > > > for us > > > >> to follow. I am hoping we have a solution for Rails 3.1 folks before > it > > > gets > > > >> officially released.
> > > >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> > > > wrote: > > > >> > In the meantime I had a pretty good experience with > jasmine-headless- > > > >> > webkit last week. I'm looking at adding a simple custom spec > runner > > > >> > ERB template that loads in the same stuff the jasmine.yml calls > for so > > > >> > you can also load the specs in browser when you want to. (Not to > work > > > >> > around or circumvent your great work, Rajan; just in the interest > in > > > >> > getting a good working solution for 3.1 today).
> > > >> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > > >> > > I think 2 and 3 (and whatever work we need to actually use the > > > pipeline) > > > >> > are > > > >> > > probably near-term priorities for the Jasmine gem, but I think > > > you're > > > >> > > correct in that it's going to take awhile to get there. We > haven't > > > been > > > >> > > great about timely acceptance of pull requests (we're trying to > get > > > that > > > >> > > better), but I'd love to see patches go into jasmine-gem rather > than > > > >> > > fragmented into another Rails 3.1-only gem.
> > > >> > > It's possible we're eventually going to be pushed into splitting > up > > > the > > > >> > gem > > > >> > > regardless. The original intent of having a single gem that > meets > > > many > > > >> > > purposes was so people could simply type `gem install jasmine` > and > > > get > > > >> > > going; as Rails 3.1 changes many things about how JS works and > Rails > > > 2 > > > >> > falls > > > >> > > farther behind Rails 3 this is getting tricky to keep in place.
> > > >> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls < > sea...@gmail.com> > > > wrote: > > > >> > > > I'm reviving this thread after independently playing with > Chris's > > > demo > > > >> > > > & also Brad's gem.
> > > >> > > > Has there been any movement on this recently? I'm really > > > interested to > > > >> > > > learn what the current options are out there for integrating > > > Jasmine > > > >> > > > with Rails. Leveraging the asset pipeline seems like the > smartest > > > >> > > > thing to do moving forward.
> > > >> > > > Things I'm interested in figuring out the best approach that > gets > > > me > > > >> > > > as many of these as possible:
> > > >> > > > 1. Headless execution for CI (worst case, one could write a > Cuke > > > that > > > >> > > > looks at a spec runner page and looks for green) > > > >> > > > 2. Dynamic coffee compilation > > > >> > > > 3. Picks up new assets/files as they're added (preventing a > high > > > >> > > > maintenance SpecRunner page) > > > >> > > > 4. SpecRunner individually sources each script as opposed to > > > >> > > > concatenating them for easier debugging. > > > >> > > > 5. RSpec integration would be nifty
> > > >> > > > I doubt the official jasmine gem is immediately headed in this > > > >> > > > direction. The asset pipeline represents such a major break > from > > > the > > > >> > > > past that it would be difficult to maintain BC. (related:
> > > >> > > > Maybe a new gem to address these and other niceties is called > for. > > > I > > > >> > > > never thought I'd expect my Jasmine workflow on Java projects > > > would > > > >> > > > feel tighter than on Rails. I'm suspicious enough of that > > > conclusion > > > >> > > > that I'm willing to bet I'm just ignorant of a better way to > do > > > it.
> > > >> > > > Thoughts?
> > > >> > > > -Justin
> > > >> > > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> > wrote: > > > >> > > > > Hi Chris,
> > > >> > > > > I've put a gem together that I think partially solves what > you > > > need.
> By default Jasmine will load files you place in spec/javascripts/helpers. > You'll want to put the version of jquery that Rails provides (and jquery-ui, > if you're using it) in there in order for Jasmine to be able to load it for > your tests. Rails normally provides these to the asset pipeline via the > jquery-rails gem, which jasmine doesn't yet interact with.
> Hope this helps!
> Thanks for using Jasmine!
> Rajan
> On Sat, Sep 17, 2011 at 4:43 PM, Lille <lille.pengu...@gmail.com> wrote:
>> Rajan,
>> Can you sketch out a little how to 'load jQuery from helpers'? I'm >> hesitant to seek to discover this issue where I employ jQuery in my >> specs, before maybe someone can indicate the trick.
>> (BTW - this is all very timely. To me, it has felt like UI behavior >> coding was always an afterthought, if at all, in Rails land. Now, with >> Node.js, the distinction is beginning to lose practical meaning, but >> it'd be nice to see Rails catch up where it can.)
>> Lille
>> On Sep 10, 2:21 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: >> > I should note that this update doesn't yet support loading jquery from >> the >> > assets path because the file doesn't exist on the local filesystem -- for >> > now it'll need to be loaded from helpers, I suppose.
>> > On Sat, Sep 10, 2011 at 1:37 PM, Rajan Agaskar <ra...@pivotallabs.com >> >wrote:
>> > > I spent a few hours this morning adding extremely basic asset pipeline >> > > support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem >> > > (http://github.com/pivotal/jasmine-gem).
>> > > Essentially the jasmine.yml file now takes asset_pipeline_paths, each >> > > path you pass here will be mapped through the Sprockets asset >> > > pipeline. We have a bit of a 'hack' in order to permit running files >> > > in the spec directory through Sprockets -- if one of your >> > > asset_pipeline_paths matches your spec_dir, we'll assume you want to >> > > use Sprockets for specs (there's a long story about why the spec dir >> > > gets mapped as __spec__ inside of relative to root, something we might >> > > re-examine in Jasmine 2).
>> > > Files passed in will now have any Sprocket compatible engine >> > > extensions stripped off so that we correctly request them from >> > > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by >> > > Jasmine as /app/assets/my_file.js.
>> > > I believe Jasmine should do the right thing if you hand it scss files >> > > in your stylesheets and coffee files in your helpers, but I haven't >> > > yet tested it.
>> > > This is a pretty minimal spike, so there may be other issues; hoping >> > > this meets the 80% case for most people -- please feel free to offer >> > > your feedback!
>> > > Thanks!
>> > > Rajan
>> > > PS: >> > > Here's a sample configuration file to use coffeescript for your src and >> > > specs:
>> > > # asset_pipeline_paths >> > > # >> > > # Paths you would like to be served by the Sprockets asset pipeline. >> > > # >> > > # If you include your spec_dir (eg: - spec/javascripts ) here, >> > > # Jasmine will use the Sprockets asset pipeline to build your spec >> files. >> > > # >> > > # Default: [] >> > > # >> > > # EXAMPLE: >> > > # asset_pipeline_paths: >> > > # - app/assets >> > > # - spec/javascripts >> > > asset_pipeline_paths: >> > > - app/assets >> > > - spec/javascripts
>> > > On Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> >> wrote: >> > > >> We are gearing up to take on the challenges of working with 3.1 and >> > > >> stuff like RequireJS
>> > > > Sounds great, I'd definitely be interested in trying out/using this >> > > > functionality when it exists.
>> > > > Thanks,
>> > > > Colin
>> > > > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: >> > > >> Awesome! We are gearing up to take on the challenges of working with >> 3.1 >> > > and >> > > >> stuff like RequireJS, so these sorts of things will be great >> examples >> > > for us >> > > >> to follow. I am hoping we have a solution for Rails 3.1 folks before >> it >> > > gets >> > > >> officially released.
>> > > >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> >> > > wrote: >> > > >> > In the meantime I had a pretty good experience with >> jasmine-headless- >> > > >> > webkit last week. I'm looking at adding a simple custom spec >> runner >> > > >> > ERB template that loads in the same stuff the jasmine.yml calls >> for so >> > > >> > you can also load the specs in browser when you want to. (Not to >> work >> > > >> > around or circumvent your great work, Rajan; just in the interest >> in >> > > >> > getting a good working solution for 3.1 today).
>> > > >> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: >> > > >> > > I think 2 and 3 (and whatever work we need to actually use the >> > > pipeline) >> > > >> > are >> > > >> > > probably near-term priorities for the Jasmine gem, but I think >> > > you're >> > > >> > > correct in that it's going to take awhile to get there. We >> haven't >> > > been >> > > >> > > great about timely acceptance of pull requests (we're trying to >> get >> > > that >> > > >> > > better), but I'd love to see patches go into jasmine-gem rather >> than >> > > >> > > fragmented into another Rails 3.1-only gem.
>> > > >> > > It's possible we're eventually going to be pushed into splitting >> up >> > > the >> > > >> > gem >> > > >> > > regardless. The original intent of having a single gem that >> meets >> > > many >> > > >> > > purposes was so people could simply type `gem install jasmine` >> and >> > > get >> > > >> > > going; as Rails 3.1 changes many things about how JS works and >> Rails >> > > 2 >> > > >> > falls >> > > >> > > farther behind Rails 3 this is getting tricky to keep in place.
>> > > >> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls < >> sea...@gmail.com> >> > > wrote: >> > > >> > > > I'm reviving this thread after independently playing with >> Chris's >> > > demo >> > > >> > > > & also Brad's gem.
>> > > >> > > > Has there been any movement on this recently? I'm really >> > > interested to >> > > >> > > > learn what the current options are out there for integrating >> > > Jasmine >> > > >> > > > with Rails. Leveraging the asset pipeline seems like the >> smartest >> > > >> > > > thing to do moving forward.
>> > > >> > > > Things I'm interested in figuring out the best approach that >> gets >> > > me >> > > >> > > > as many of these as possible:
>> > > >> > > > 1. Headless execution for CI (worst case, one could write a >> Cuke >> > > that >> > > >> > > > looks at a spec runner page and looks for green) >> > > >> > > > 2. Dynamic coffee compilation >> > > >> > > > 3. Picks up new assets/files as they're added (preventing a >> high >> > > >> > > > maintenance SpecRunner page) >> > > >> > > > 4. SpecRunner individually sources each script as opposed to >> > > >> > > > concatenating them for easier debugging. >> > > >> > > > 5. RSpec integration would be nifty
>> > > >> > > > I doubt the official jasmine gem is immediately headed in this >> > > >> > > > direction. The asset pipeline represents such a major break >> from >> > > the >> > > >> > > > past that it would be difficult to maintain BC. (related:
>> > > >> > > > Maybe a new gem to address these and other niceties is called >> for. >> > > I >> > > >> > > > never thought I'd expect my Jasmine workflow on Java projects >> > > would >> > > >> > > > feel tighter than on Rails. I'm suspicious enough of that >> > > conclusion >> > > >> > > > that I'm
Thanks Rajan, for your post and change to jasmine.
I can confirm positive results from use of Rajan's update to jasmine
for my Rails 3.1 project involving tests of backbone.js using
CoffeeScript.
Rajan, for my part, I'd like to encourage you good folks at pivotal to
make any reasonable additional efforts to fully inculcate Rails 3.1
compatibility in the gem, as I expect it will be very useful to the
community.
Here is my version of Rajan's jasmine.yml:
# src_files
#
# Return an array of filepaths relative to src_dir to include before
jasmine specs.
# Default: []
#
# EXAMPLE:
#
# src_files:
# - lib/source1.js
# - lib/source2.js
# - dist/**/*.js
#
src_files:
- spec/javascripts/helpers/jquery-1.6.2.js
- spec/javascripts/helpers/jasmine_jquery-1.3.1.js
- vendor/assets/javascripts/underscore.js
- vendor/assets/javascripts/backbone.js
- vendor/assets/javascripts/backbone.localStorage-min.js
- vendor/assets/javascripts/handlebars.js
- app/assets/javascripts/backbone/fha2.js.coffee
# stylesheets
#
# Return an array of stylesheet filepaths relative to src_dir to
include before jasmine specs.
# Default: []
#
# EXAMPLE:
#
# stylesheets:
# - css/style.css
# - stylesheets/*.css
#
stylesheets:
- stylesheets/**/*.css
# helpers
#
# Return an array of filepaths relative to spec_dir to include before
jasmine specs.
# Default: ["helpers/**/*.js"]
#
# EXAMPLE:
#
# helpers:
# - helpers/**/*.js
#
helpers:
- helpers/**/*.js
# - helpers/jquery.js
# - helpers/jquery-ui.js
# - helpers/jquery_ujs.js
# - helpers/jasmine_jquery-1.3.1.js
# spec_files
#
# Return an array of filepaths relative to spec_dir to include.
# Default: ["**/*[sS]pec.js"]
#
# EXAMPLE:
#
# spec_files:
# - **/*[sS]pec.js
#
spec_files:
- '**/*[sS]pec.js'
- '**/*[sS]pec.js.coffee'
# src_dir
#
# Source directory path. Your src_files must be returned relative to
this path. Will use root if left blank.
# Default: project root
#
# EXAMPLE:
#
# src_dir: public
#
src_dir:
# spec_dir
#
# Spec directory path. Your spec_files must be returned relative to
this path.
# Default: spec/javascripts
#
# EXAMPLE:
#
# spec_dir: spec/javascripts
#
spec_dir: spec/javascripts
# asset_pipeline_paths
#
# Paths you would like to be served by the Sprockets asset pipeline.
#
# If you include your spec_dir (eg: - spec/javascripts ) here,
# Jasmine will use the Sprockets asset pipeline to build your spec
files.
#
# Default: []
#
# EXAMPLE:
asset_pipeline_paths:
- app/assets
- spec/javascripts
I used the backbone-rails gem to generate backbone stuff in this app.
In particular, app/assets/javascripts/backbone/fha2.js.coffee is as
follows:
> > By default Jasmine will load files you place in spec/javascripts/helpers.
> > You'll want to put the version of jquery that Rails provides (and
> jquery-ui,
> > if you're using it) in there in order for Jasmine to be able to load it
> for
> > your tests. Rails normally provides these to the asset pipeline via the
> > jquery-rails gem, which jasmine doesn't yet interact with.
> > Hope this helps!
> > Thanks for using Jasmine!
> > Rajan
> > On Sat, Sep 17, 2011 at 4:43 PM, Lille <lille.pengu...@gmail.com> wrote:
> >> Rajan,
> >> Can you sketch out a little how to 'load jQuery from helpers'? I'm
> >> hesitant to seek to discover this issue where I employ jQuery in my
> >> specs, before maybe someone can indicate the trick.
> >> (BTW - this is all very timely. To me, it has felt like UI behavior
> >> coding was always an afterthought, if at all, in Rails land. Now, with
> >> Node.js, the distinction is beginning to lose practical meaning, but
> >> it'd be nice to see Rails catch up where it can.)
> >> Lille
> >> On Sep 10, 2:21 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> >> > I should note that this update doesn't yet support loading jquery from
> >> the
> >> > assets path because the file doesn't exist on the local filesystem --
> for
> >> > now it'll need to be loaded from helpers, I suppose.
> >> > On Sat, Sep 10, 2011 at 1:37 PM, Rajan Agaskar <ra...@pivotallabs.com
> >> >wrote:
> >> > > I spent a few hours this morning adding extremely basic asset
> pipeline
> >> > > support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem
> >> > > (http://github.com/pivotal/jasmine-gem).
> >> > > Essentially the jasmine.yml file now takes asset_pipeline_paths, each
> >> > > path you pass here will be mapped through the Sprockets asset
> >> > > pipeline. We have a bit of a 'hack' in order to permit running files
> >> > > in the spec directory through Sprockets -- if one of your
> >> > > asset_pipeline_paths matches your spec_dir, we'll assume you want to
> >> > > use Sprockets for specs (there's a long story about why the spec dir
> >> > > gets mapped as __spec__ inside of relative to root, something we
> might
> >> > > re-examine in Jasmine 2).
> >> > > Files passed in will now have any Sprocket compatible engine
> >> > > extensions stripped off so that we correctly request them from
> >> > > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by
> >> > > Jasmine as /app/assets/my_file.js.
> >> > > I believe Jasmine should do the right thing if you hand it scss files
> >> > > in your stylesheets and coffee files in your helpers, but I haven't
> >> > > yet tested it.
> >> > > This is a pretty minimal spike, so there may be other issues; hoping
> >> > > this meets the 80% case for most people -- please feel free to offer
> >> > > your feedback!
> >> > > Thanks!
> >> > > Rajan
> >> > > PS:
> >> > > Here's a sample configuration file to use coffeescript for your src
> and
> >> > > specs:
> >> > > # asset_pipeline_paths
> >> > > #
> >> > > # Paths you would like to be served by the Sprockets asset pipeline.
> >> > > #
> >> > > # If you include your spec_dir (eg: - spec/javascripts ) here,
> >> > > # Jasmine will use the Sprockets asset pipeline to build your spec
> >> files.
> >> > > #
> >> > > # Default: []
> >> > > #
> >> > > # EXAMPLE:
> >> > > # asset_pipeline_paths:
> >> > > # - app/assets
> >> > > # - spec/javascripts
> >> > > asset_pipeline_paths:
> >> > > - app/assets
> >> > > - spec/javascripts
> >> > > On Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com>
> >> wrote:
> >> > > >> We are gearing up to take on the challenges of working with 3.1
> and
> >> > > >> stuff like RequireJS
> >> > > > Sounds great, I'd definitely be interested in trying out/using this
> >> > > > functionality when it exists.
> >> > > > Thanks,
> >> > > > Colin
> >> > > > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> >> > > >> Awesome! We are gearing up to take on the challenges of working
> with
> >> 3.1
> >> > > and
> >> > > >> stuff like RequireJS, so these sorts of things will be great
> >> examples
> >> > > for us
> >> > > >> to follow. I am hoping we have a solution for Rails 3.1 folks
> before
> >> it
> >> > > gets
> >> > > >> officially released.
> >> > > >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com>
> >> > > wrote:
> >> > > >> > In the meantime I had a pretty good experience with
> >> jasmine-headless-
> >> > > >> > webkit
On Sun, Sep 18, 2011 at 8:37 PM, Lille <lille.pengu...@gmail.com> wrote: > Thanks Rajan, for your post and change to jasmine.
> I can confirm positive results from use of Rajan's update to jasmine > for my Rails 3.1 project involving tests of backbone.js using > CoffeeScript.
> Rajan, for my part, I'd like to encourage you good folks at pivotal to > make any reasonable additional efforts to fully inculcate Rails 3.1 > compatibility in the gem, as I expect it will be very useful to the > community.
> # src_dir > # > # Source directory path. Your src_files must be returned relative to > this path. Will use root if left blank. > # Default: project root > # > # EXAMPLE: > # > # src_dir: public > # > src_dir:
> # spec_dir > # > # Spec directory path. Your spec_files must be returned relative to > this path. > # Default: spec/javascripts > # > # EXAMPLE: > # > # spec_dir: spec/javascripts > # > spec_dir: spec/javascripts
> # asset_pipeline_paths > # > # Paths you would like to be served by the Sprockets asset pipeline. > # > # If you include your spec_dir (eg: - spec/javascripts ) here, > # Jasmine will use the Sprockets asset pipeline to build your spec > files. > # > # Default: [] > # > # EXAMPLE: > asset_pipeline_paths: > - app/assets > - spec/javascripts
> I used the backbone-rails gem to generate backbone stuff in this app. > In particular, app/assets/javascripts/backbone/fha2.js.coffee is as > follows:
> On Sep 18, 12:46 am, Brad Phelan <bradphe...@xtargets.com> wrote: > > As an alternative look at the jasminerice gem which does work with the > rails > > 3.1 asset pipeline.
> > > By default Jasmine will load files you place in > spec/javascripts/helpers. > > > You'll want to put the version of jquery that Rails provides (and > > jquery-ui, > > > if you're using it) in there in order for Jasmine to be able to load it > > for > > > your tests. Rails normally provides these to the asset pipeline via the > > > jquery-rails gem, which jasmine doesn't yet interact with.
> > > Hope this helps!
> > > Thanks for using Jasmine!
> > > Rajan
> > > On Sat, Sep 17, 2011 at 4:43 PM, Lille <lille.pengu...@gmail.com> > wrote:
> > >> Rajan,
> > >> Can you sketch out a little how to 'load jQuery from helpers'? I'm > > >> hesitant to seek to discover this issue where I employ jQuery in my > > >> specs, before maybe someone can indicate the trick.
> > >> (BTW - this is all very timely. To me, it has felt like UI behavior > > >> coding was always an afterthought, if at all, in Rails land. Now, with > > >> Node.js, the distinction is beginning to lose practical meaning, but > > >> it'd be nice to see Rails catch up where it can.)
> > >> Lille
> > >> On Sep 10, 2:21 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > >> > I should note that this update doesn't yet support loading jquery > from > > >> the > > >> > assets path because the file doesn't exist on the local filesystem > -- > > for > > >> > now it'll need to be loaded from helpers, I suppose.
> > >> > On Sat, Sep 10, 2011 at 1:37 PM, Rajan Agaskar < > ra...@pivotallabs.com > > >> >wrote:
> > >> > > I spent a few hours this morning adding extremely basic asset > > pipeline > > >> > > support. The changes are pushed to the 1.2.rc1 branch of > jasmine-gem > > >> > > (http://github.com/pivotal/jasmine-gem).
> > >> > > Essentially the jasmine.yml file now takes asset_pipeline_paths, > each > > >> > > path you pass here will be mapped through the Sprockets asset > > >> > > pipeline. We have a bit of a 'hack' in order to permit running > files > > >> > > in the spec directory through Sprockets -- if one of your > > >> > > asset_pipeline_paths matches your spec_dir, we'll assume you want > to > > >> > > use Sprockets for specs (there's a long story about why the spec > dir > > >> > > gets mapped as __spec__ inside of relative to root, something we > > might > > >> > > re-examine in Jasmine 2).
> > >> > > Files passed in will now have any Sprocket compatible engine > > >> > > extensions stripped off so that we correctly request them from > > >> > > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by > > >> > > Jasmine as /app/assets/my_file.js.
> > >> > > I believe Jasmine should do the right thing if you hand it scss > files > > >> > > in your stylesheets and coffee files in your helpers, but I > haven't > > >> > > yet tested it.
> > >> > > This is a pretty minimal spike, so there may be other issues; > hoping > > >> > > this meets the 80% case for most people -- please feel free to > offer > > >> > > your feedback!
> > >> > > Thanks!
> > >> > > Rajan
> > >> > > PS: > > >> > > Here's a sample configuration file to use coffeescript for your > src > > and > > >> > > specs:
> > >> > > # asset_pipeline_paths > > >> > > # > > >> > > # Paths you would like to be served by the Sprockets asset > pipeline. > > >> > > # > > >> > > # If you include your spec_dir (eg: - spec/javascripts ) here, > > >> > > # Jasmine will use the Sprockets asset pipeline to build your spec > > >> files. > > >> > > # > > >> > > # Default: [] > > >> > > # > > >> > > # EXAMPLE: > > >> > > # asset_pipeline_paths: > > >> > > # - app/assets > > >> > > # - spec/javascripts > > >> > > asset_pipeline_paths: > > >> > > - app/assets > > >> > > - spec/javascripts
> > >> > > On Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> > > >> wrote: > > >> > > >> We are gearing up to take on the challenges of working with 3.1 > > and > > >> > > >> stuff like RequireJS
> > >> > > > Sounds great, I'd definitely be interested in trying out/using > this
> On Sun, Sep 18, 2011 at 8:37 PM, Lille <lille.pengu...@gmail.com> wrote:
>> Thanks Rajan, for your post and change to jasmine.
>> I can confirm positive results from use of Rajan's update to jasmine >> for my Rails 3.1 project involving tests of backbone.js using >> CoffeeScript.
>> Rajan, for my part, I'd like to encourage you good folks at pivotal to >> make any reasonable additional efforts to fully inculcate Rails 3.1 >> compatibility in the gem, as I expect it will be very useful to the >> community.
>> # src_dir >> # >> # Source directory path. Your src_files must be returned relative to >> this path. Will use root if left blank. >> # Default: project root >> # >> # EXAMPLE: >> # >> # src_dir: public >> # >> src_dir:
>> # spec_dir >> # >> # Spec directory path. Your spec_files must be returned relative to >> this path. >> # Default: spec/javascripts >> # >> # EXAMPLE: >> # >> # spec_dir: spec/javascripts >> # >> spec_dir: spec/javascripts
>> # asset_pipeline_paths >> # >> # Paths you would like to be served by the Sprockets asset pipeline. >> # >> # If you include your spec_dir (eg: - spec/javascripts ) here, >> # Jasmine will use the Sprockets asset pipeline to build your spec >> files. >> # >> # Default: [] >> # >> # EXAMPLE: >> asset_pipeline_paths: >> - app/assets >> - spec/javascripts
>> I used the backbone-rails gem to generate backbone stuff in this app. >> In particular, app/assets/javascripts/backbone/fha2.js.coffee is as >> follows:
>> On Sep 18, 12:46 am, Brad Phelan <bradphe...@xtargets.com> wrote: >> > As an alternative look at the jasminerice gem which does work with the >> rails >> > 3.1 asset pipeline.
>> > > By default Jasmine will load files you place in >> spec/javascripts/helpers. >> > > You'll want to put the version of jquery that Rails provides (and >> > jquery-ui, >> > > if you're using it) in there in order for Jasmine to be able to load >> it >> > for >> > > your tests. Rails normally provides these to the asset pipeline via >> the >> > > jquery-rails gem, which jasmine doesn't yet interact with.
>> > > Hope this helps!
>> > > Thanks for using Jasmine!
>> > > Rajan
>> > > On Sat, Sep 17, 2011 at 4:43 PM, Lille <lille.pengu...@gmail.com> >> wrote:
>> > >> Rajan,
>> > >> Can you sketch out a little how to 'load jQuery from helpers'? I'm >> > >> hesitant to seek to discover this issue where I employ jQuery in my >> > >> specs, before maybe someone can indicate the trick.
>> > >> (BTW - this is all very timely. To me, it has felt like UI behavior >> > >> coding was always an afterthought, if at all, in Rails land. Now, >> with >> > >> Node.js, the distinction is beginning to lose practical meaning, but >> > >> it'd be nice to see Rails catch up where it can.)
>> > >> Lille
>> > >> On Sep 10, 2:21 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: >> > >> > I should note that this update doesn't yet support loading jquery >> from >> > >> the >> > >> > assets path because the file doesn't exist on the local filesystem >> -- >> > for >> > >> > now it'll need to be loaded from helpers, I suppose.
>> > >> > On Sat, Sep 10, 2011 at 1:37 PM, Rajan Agaskar < >> ra...@pivotallabs.com >> > >> >wrote:
>> > >> > > I spent a few hours this morning adding extremely basic asset >> > pipeline >> > >> > > support. The changes are pushed to the 1.2.rc1 branch of >> jasmine-gem >> > >> > > (http://github.com/pivotal/jasmine-gem).
>> > >> > > Essentially the jasmine.yml file now takes asset_pipeline_paths, >> each >> > >> > > path you pass here will be mapped through the Sprockets asset >> > >> > > pipeline. We have a bit of a 'hack' in order to permit running >> files >> > >> > > in the spec directory through Sprockets -- if one of your >> > >> > > asset_pipeline_paths matches your spec_dir, we'll assume you want >> to >> > >> > > use Sprockets for specs (there's a long story about why the spec >> dir >> > >> > > gets mapped as __spec__ inside of relative to root, something we >> > might >> > >> > > re-examine in Jasmine 2).
>> > >> > > Files passed in will now have any Sprocket compatible engine >> > >> > > extensions stripped off so that we correctly request them from >> > >> > > Sprockets -- ie, app/assets/my_file.js.coffee will be requested >> by >> > >> > > Jasmine as /app/assets/my_file.js.
>> > >> > > I believe Jasmine should do the right thing if you hand it scss >> files >> > >> > > in your stylesheets and coffee files in your helpers, but I >> haven't >> > >> > > yet tested it.
>> > >> > > This is a pretty minimal spike, so there may be other issues; >> hoping >> > >> > > this meets the 80% case for most people -- please feel free to >> offer >> > >> > > your feedback!
>> > >> > > Thanks!
>> > >> > > Rajan
>> > >> > > PS: >> > >> > > Here's a sample configuration file to use coffeescript for your >> src >> > and >> > >> > > specs:
>> > >> > > # asset_pipeline_paths >> > >> > > # >> > >> > > # Paths you would like to be served by the Sprockets asset >> pipeline. >> > >> > > # >> > >> > > # If you include your spec_dir (eg: - spec/javascripts ) here, >> > >> > > # Jasmine will use the Sprockets asset pipeline to
asset_pipeline_paths:
- app/assets
- spec/javascripts
--------------------------------------------------------------------------- -------------
... and it worked fine for all JS files.
When I changed the src files to
--------------------------------------------------------------------------- -------------
src_files:
- app/assets/**/*.js
- app/assets/**/*.js.coffee
--------------------------------------------------------------------------- -------------
The server starts, but hangs when I refresh the browser.
Any ideas? I've been digging through the source, but I can't seem to
find where the trouble starts.
Thanks!
- K
On Sep 10, 10:37 am, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> I spent a few hours this morning adding extremely basic asset pipeline
> support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem
> (http://github.com/pivotal/jasmine-gem).
> Essentially the jasmine.yml file now takes asset_pipeline_paths, each
> path you pass here will be mapped through the Sprockets asset
> pipeline. We have a bit of a 'hack' in order to permit running files
> in the spec directory through Sprockets -- if one of your
> asset_pipeline_paths matches your spec_dir, we'll assume you want to
> use Sprockets for specs (there's a long story about why the spec dir
> gets mapped as __spec__ inside of relative to root, something we might
> re-examine in Jasmine 2).
> Files passed in will now have any Sprocket compatible engine
> extensions stripped off so that we correctly request them from
> Sprockets -- ie, app/assets/my_file.js.coffee will be requested by
> Jasmine as /app/assets/my_file.js.
> I believe Jasmine should do the right thing if you hand it scss files
> in your stylesheets and coffee files in your helpers, but I haven't
> yet tested it.
> This is a pretty minimal spike, so there may be other issues; hoping
> this meets the 80% case for most people -- please feel free to offer
> your feedback!
> Thanks!
> Rajan
> PS:
> Here's a sample configuration file to use coffeescript for your src and specs:
> # src_files
> #
> # Return an array of filepaths relative to src_dir to include before
> jasmine specs.
> # Default: []
> #
> # EXAMPLE:
> #
> # src_files:
> # - lib/source1.js
> # - lib/source2.js
> # - dist/**/*.js
> #
> src_files:
> - "app/assets/**/*.coffee"
> # stylesheets
> #
> # Return an array of stylesheet filepaths relative to src_dir to
> include before jasmine specs.
> # Default: []
> #
> # EXAMPLE:
> #
> # stylesheets:
> # - css/style.css
> # - stylesheets/*.css
> #
> stylesheets:
> - stylesheets/**/*.css
> # helpers
> #
> # Return an array of filepaths relative to spec_dir to include before
> jasmine specs.
> # Default: ["helpers/**/*.js"]
> #
> # EXAMPLE:
> #
> # helpers:
> # - helpers/**/*.js
> #
> helpers:
> - helpers/**/*.js
> # src_dir
> #
> # Source directory path. Your src_files must be returned relative to
> this path. Will use root if left blank.
> # Default: project root
> #
> # EXAMPLE:
> #
> # src_dir: public
> #
> src_dir:
> # spec_dir
> #
> # Spec directory path. Your spec_files must be returned relative to this path.
> # Default: spec/javascripts
> #
> # EXAMPLE:
> #
> # spec_dir: spec/javascripts
> #
> spec_dir: spec/javascripts
> # asset_pipeline_paths
> #
> # Paths you would like to be served by the Sprockets asset pipeline.
> #
> # If you include your spec_dir (eg: - spec/javascripts ) here,
> # Jasmine will use the Sprockets asset pipeline to build your spec files.
> #
> # Default: []
> #
> # EXAMPLE:
> # asset_pipeline_paths:
> # - app/assets
> # - spec/javascripts
> asset_pipeline_paths:
> - app/assets
> - spec/javascriptsOn Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> wrote:
> >> We are gearing up to take on the challenges of working with 3.1 and
> >> stuff like RequireJS
> > Sounds great, I'd definitely be interested in trying out/using this
> > functionality when it exists.
> > Thanks,
> > Colin
> > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> >> Awesome! We are gearing up to take on the challenges of working with 3.1 and
> >> stuff like RequireJS, so these sorts of things will be great examples for us
> >> to follow. I am hoping we have a solution for Rails 3.1 folks before it gets
> >> officially released.
> >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> wrote:
> >> > In the meantime I had a pretty good experience with jasmine-headless-
> >> > webkit last week. I'm looking at adding a simple custom spec runner
> >> > ERB template that loads in the same stuff the jasmine.yml calls for so
> >> > you can also load the specs in browser when you want to. (Not to work
> >> > around or circumvent your great work, Rajan; just in the interest in
> >> > getting a good working solution for 3.1 today).
> >> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> >> > > I think 2 and 3 (and whatever work we need to actually use the pipeline)
> >> > are
> >> > > probably near-term priorities for the Jasmine gem, but I think you're
> >> > > correct in that it's going to take awhile to get there. We haven't been
> >> > > great about timely acceptance of pull requests (we're trying to get that
> >> > > better), but I'd love to see patches go into jasmine-gem rather than
> >> > > fragmented into another Rails 3.1-only gem.
> >> > > It's possible we're eventually going to be pushed into splitting up the
> >> > gem
> >> > > regardless. The original intent of having a single gem that meets many
> >> > > purposes was so people could simply type `gem install jasmine` and get
> >> > > going; as Rails 3.1 changes many things about how JS works and Rails 2
> >> > falls
> >> > > farther behind Rails 3 this is getting tricky to keep in place.
> >> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> wrote:
> >> > > > I'm reviving this thread after independently playing with Chris's demo
> >> > > > & also Brad's gem.
> >> > > > Has there been any movement on this recently? I'm really interested to
> >> > > > learn what the current options are out there for integrating Jasmine
> >> > > > with Rails. Leveraging the asset pipeline seems like the smartest
> >> > > > thing to do moving forward.
> >> > > > Things I'm interested in figuring out the best approach that gets me
> >> > > > as many of these as possible:
> >> > > > 1. Headless execution for CI (worst case, one could write a Cuke that
> >> > > > looks at a spec runner page and looks for green)
> >> > > > 2. Dynamic coffee compilation
> >> > > > 3. Picks up new assets/files as they're added (preventing a high
> >> > > > maintenance SpecRunner page)
> >> > > > 4. SpecRunner individually sources each script as opposed to
> >> > > > concatenating them for easier debugging.
> >> > > > 5. RSpec integration would be nifty
> >> > > > I doubt the official jasmine gem is immediately headed in this
> >> > > > direction. The asset pipeline represents such a major break from the
> >> > > > past that it would be difficult to maintain BC. (related:
> >> > > > Maybe a new gem to address these and other niceties is called for. I
> >> > > > never thought I'd expect my Jasmine workflow on Java projects would
> >> > > > feel tighter than on Rails. I'm suspicious enough of that conclusion
> >> > > > that I'm willing to bet I'm just ignorant of a better way to do it.
> >> > > > Thoughts?
> >> > > > -Justin
> >> > > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote:
> >> > > > > Hi Chris,
> >> > > > > I've put a gem together that I think partially solves what you need.
> >> > > > > I've got jasmin working with the Rails 3.1 and the asset pipeline and
> >> > > > it's
> >> > > > > possible
> >> > > > > to pull assets into the specs that are gem packaged.
> >> > > > > Perhaps if the features are not quite what you need you could use it
> >> > as a
> >> > > > > starting point.
> >> > > > > I only threw it together yesterday after getting frustrated with the
> >> > > > current
> >> > > > > jasmine gem.
> >> > > > > Regards
> >> > > > > Brad
> >> > > > --
> >> > > > You received this message because you are subscribed to the Google
> >> > Groups
> >> > > > "Jasmine" group.
> >> > > > To post to this group, send email to jasmine-js@googlegroups.com.
> >> > > > To unsubscribe from this group, send email to
> >> > > > jasmine-js+unsubscribe@googlegroups.com.
> >> > > > For more options, visit this group at
> >> > > >http://groups.google.com/group/jasmine-js?hl=en.
> >> > --
> >> > You received this message because you are subscribed to the Google Groups
> >> > "Jasmine" group.
> >> > To post to this group, send email to jasmine-js@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > jasmine-js+unsubscribe@googlegroups.com.
> >> > For more options,
Hmm that's odd. Mine is essentially the same. Only different being is i specify the files i need in a particular order cause of dependencies. Here's mine: http://pastie.org/2618361
On Wed, Sep 28, 2011 at 8:45 PM, Kevin Fitzpatrick <ke...@pivotalsf.com>wrote:
> The server starts, but hangs when I refresh the browser.
> Any ideas? I've been digging through the source, but I can't seem to > find where the trouble starts.
> Thanks! > - K > On Sep 10, 10:37 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > I spent a few hours this morning adding extremely basic asset pipeline > > support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem > > (http://github.com/pivotal/jasmine-gem).
> > Essentially the jasmine.yml file now takes asset_pipeline_paths, each > > path you pass here will be mapped through the Sprockets asset > > pipeline. We have a bit of a 'hack' in order to permit running files > > in the spec directory through Sprockets -- if one of your > > asset_pipeline_paths matches your spec_dir, we'll assume you want to > > use Sprockets for specs (there's a long story about why the spec dir > > gets mapped as __spec__ inside of relative to root, something we might > > re-examine in Jasmine 2).
> > Files passed in will now have any Sprocket compatible engine > > extensions stripped off so that we correctly request them from > > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by > > Jasmine as /app/assets/my_file.js.
> > I believe Jasmine should do the right thing if you hand it scss files > > in your stylesheets and coffee files in your helpers, but I haven't > > yet tested it.
> > This is a pretty minimal spike, so there may be other issues; hoping > > this meets the 80% case for most people -- please feel free to offer > > your feedback!
> > Thanks!
> > Rajan
> > PS: > > Here's a sample configuration file to use coffeescript for your src and > specs:
> > # src_dir > > # > > # Source directory path. Your src_files must be returned relative to > > this path. Will use root if left blank. > > # Default: project root > > # > > # EXAMPLE: > > # > > # src_dir: public > > # > > src_dir:
> > # spec_dir > > # > > # Spec directory path. Your spec_files must be returned relative to this > path. > > # Default: spec/javascripts > > # > > # EXAMPLE: > > # > > # spec_dir: spec/javascripts > > # > > spec_dir: spec/javascripts
> > # asset_pipeline_paths > > # > > # Paths you would like to be served by the Sprockets asset pipeline. > > # > > # If you include your spec_dir (eg: - spec/javascripts ) here, > > # Jasmine will use the Sprockets asset pipeline to build your spec files. > > # > > # Default: [] > > # > > # EXAMPLE: > > # asset_pipeline_paths: > > # - app/assets > > # - spec/javascripts > > asset_pipeline_paths: > > - app/assets > > - spec/javascriptsOn Sun, Sep 4, 2011 at 6:06 PM, Colin Jack < > colin.j...@gmail.com> wrote: > > >> We are gearing up to take on the challenges of working with 3.1 and > > >> stuff like RequireJS
> > > Sounds great, I'd definitely be interested in trying out/using this > > > functionality when it exists.
> > > Thanks,
> > > Colin
> > > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > >> Awesome! We are gearing up to take on the challenges of working with > 3.1 and > > >> stuff like RequireJS, so these sorts of things will be great examples > for us > > >> to follow. I am hoping we have a solution for Rails 3.1 folks before > it gets > > >> officially released.
> > >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> > wrote: > > >> > In the meantime I had a pretty good experience with > jasmine-headless- > > >> > webkit last week. I'm looking at adding a simple custom spec runner > > >> > ERB template that loads in the same stuff the jasmine.yml calls for > so > > >> > you can also load the specs in browser when you want to. (Not to > work > > >> > around or circumvent your great work, Rajan; just in the interest in > > >> > getting a good working solution for 3.1 today).
> > >> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > >> > > I think 2 and 3 (and whatever work we need to actually use the > pipeline) > > >> > are > > >> > > probably near-term priorities for the Jasmine gem, but I think > you're > > >> > > correct in that it's going to take awhile to get there. We haven't > been > > >> > > great about timely acceptance of pull requests (we're trying to > get that > > >> > > better), but I'd love to see patches go into jasmine-gem rather > than > > >> > > fragmented into another Rails 3.1-only gem.
> > >> > > It's possible we're eventually going to be pushed into splitting > up the > > >> > gem > > >> > > regardless. The original intent of having a single gem that meets > many > > >> > > purposes was so people could simply type `gem install jasmine` and > get > > >> > > going; as Rails 3.1 changes many things about how JS works and > Rails 2 > > >> > falls > > >> > > farther behind Rails 3 this is getting tricky to keep in place.
> > >> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> > wrote: > > >> > > > I'm reviving this thread after independently playing with > Chris's demo > > >> > > > & also Brad's gem.
> > >> > > > Has there been any movement on this recently? I'm really > interested to > > >> > > > learn what the current options are out there for integrating > Jasmine > > >> > > > with Rails. Leveraging the asset pipeline seems like the > smartest > > >> > > > thing to do moving forward.
> > >> > > > Things I'm interested in figuring out the best approach that > gets me > > >> > > > as many of these as possible:
> > >> > > > 1. Headless execution for CI (worst case, one could write a Cuke > that > > >> > > > looks at a spec runner page and looks for green) > > >> > > > 2. Dynamic coffee compilation > > >> > > > 3. Picks up new assets/files as they're added (preventing a high > > >> > > > maintenance SpecRunner page) > > >> > > > 4. SpecRunner individually sources each script as opposed to > > >> > > > concatenating them for easier debugging. > > >> > > > 5. RSpec integration would be nifty
> > >> > > > I doubt the official jasmine gem is immediately headed in this > > >> > > > direction. The asset pipeline represents such a major break from > the > > >> > > > past that it would be difficult to maintain BC. (related:
> > >> > > > Maybe a new gem to address these and other niceties is called > for. I > > >> > > > never thought I'd expect my Jasmine workflow on Java projects > would > > >> > > > feel tighter than on Rails. I'm suspicious enough of that > conclusion > > >> > > > that I'm willing to bet I'm just ignorant of a better way to do > it.
> > >> > > > Thoughts?
> > >> > > > -Justin
> > >> > > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> > wrote: > > >> > > > > Hi Chris,
> > >> > > > > I've put a gem together that I think partially solves what you > need.
> > >> > > > > I've got jasmin working with the Rails 3.1 and the asset > pipeline and > > >> > > > it's > > >> > > > > possible > > >> > > > > to pull assets into the specs that are gem packaged.
> > >> > > > > Perhaps if the features are not quite what you need you could > use it > > >> > as a > > >> > > > > starting point. > > >> > > > > I only threw it together yesterday after getting frustrated > with the > > >> > > > current > > >> > > > > jasmine gem.
> > >> > > > > Regards
> > >> > > > > Brad
> > >> > > > -- > > >> > > > You received this message because you are subscribed to the > Google > > >> > Groups > > >> > > > "Jasmine" group. > > >> > > > To post to this
> Hmm that's odd. Mine is essentially the same. Only different being is i specify the files i need in a particular order cause of dependencies. Here's mine: http://pastie.org/2618361
> On Wed, Sep 28, 2011 at 8:45 PM, Kevin Fitzpatrick <ke...@pivotalsf.com> wrote: > I just tried this out with this jasmine.yml:
> asset_pipeline_paths: > - app/assets > - spec/javascripts > --------------------------------------------------------------------------- ------------- > ... and it worked fine for all JS files.
> When I changed the src files to > --------------------------------------------------------------------------- ------------- > src_files: > - app/assets/**/*.js > - app/assets/**/*.js.coffee > --------------------------------------------------------------------------- -------------
> The server starts, but hangs when I refresh the browser.
> Any ideas? I've been digging through the source, but I can't seem to > find where the trouble starts.
> Thanks! > - K > On Sep 10, 10:37 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > I spent a few hours this morning adding extremely basic asset pipeline > > support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem > > (http://github.com/pivotal/jasmine-gem).
> > Essentially the jasmine.yml file now takes asset_pipeline_paths, each > > path you pass here will be mapped through the Sprockets asset > > pipeline. We have a bit of a 'hack' in order to permit running files > > in the spec directory through Sprockets -- if one of your > > asset_pipeline_paths matches your spec_dir, we'll assume you want to > > use Sprockets for specs (there's a long story about why the spec dir > > gets mapped as __spec__ inside of relative to root, something we might > > re-examine in Jasmine 2).
> > Files passed in will now have any Sprocket compatible engine > > extensions stripped off so that we correctly request them from > > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by > > Jasmine as /app/assets/my_file.js.
> > I believe Jasmine should do the right thing if you hand it scss files > > in your stylesheets and coffee files in your helpers, but I haven't > > yet tested it.
> > This is a pretty minimal spike, so there may be other issues; hoping > > this meets the 80% case for most people -- please feel free to offer > > your feedback!
> > Thanks!
> > Rajan
> > PS: > > Here's a sample configuration file to use coffeescript for your src and specs:
> > # src_dir > > # > > # Source directory path. Your src_files must be returned relative to > > this path. Will use root if left blank. > > # Default: project root > > # > > # EXAMPLE: > > # > > # src_dir: public > > # > > src_dir:
> > # spec_dir > > # > > # Spec directory path. Your spec_files must be returned relative to this path. > > # Default: spec/javascripts > > # > > # EXAMPLE: > > # > > # spec_dir: spec/javascripts > > # > > spec_dir: spec/javascripts
> > # asset_pipeline_paths > > # > > # Paths you would like to be served by the Sprockets asset pipeline. > > # > > # If you include your spec_dir (eg: - spec/javascripts ) here, > > # Jasmine will use the Sprockets asset pipeline to build your spec files. > > # > > # Default: [] > > # > > # EXAMPLE: > > # asset_pipeline_paths: > > # - app/assets > > # - spec/javascripts > > asset_pipeline_paths: > > - app/assets > > - spec/javascriptsOn Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> wrote: > > >> We are gearing up to take on the challenges of working with 3.1 and > > >> stuff like RequireJS
> > > Sounds great, I'd definitely be interested in trying out/using this > > > functionality when it exists.
> > > Thanks,
> > > Colin
> > > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > >> Awesome! We are gearing up to take on the challenges of working with 3.1 and > > >> stuff like RequireJS, so these sorts of things will be great examples for us > > >> to follow. I am hoping we have a solution for Rails 3.1 folks before it gets > > >> officially released.
> > >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> wrote: > > >> > In the meantime I had a pretty good experience with jasmine-headless- > > >> > webkit last week. I'm looking at adding a simple custom spec runner > > >> > ERB template that loads in the same stuff the jasmine.yml calls for so > > >> > you can also load the specs in browser when you want to. (Not to work > > >> > around or circumvent your great work, Rajan; just in the interest in > > >> > getting a good working solution for 3.1 today).
> > >> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote: > > >> > > I think 2 and 3 (and whatever work we need to actually use the pipeline) > > >> > are > > >> > > probably near-term priorities for the Jasmine gem, but I think you're > > >> > > correct in that it's going to take awhile to get there. We haven't been > > >> > > great about timely acceptance of pull requests (we're trying to get that > > >> > > better), but I'd love to see patches go into jasmine-gem rather than > > >> > > fragmented into another Rails 3.1-only gem.
> > >> > > It's possible we're eventually going to be pushed into splitting up the > > >> > gem > > >> > > regardless. The original intent of having a single gem that meets many > > >> > > purposes was so people could simply type `gem install jasmine` and get > > >> > > going; as Rails 3.1 changes many things about how JS works and Rails 2 > > >> > falls > > >> > > farther behind Rails 3 this is getting tricky to keep in place.
> > >> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> wrote: > > >> > > > I'm reviving this thread after independently playing with Chris's demo > > >> > > > & also Brad's gem.
> > >> > > > Has there been any movement on this recently? I'm really interested to > > >> > > > learn what the current options are out there for integrating Jasmine > > >> > > > with Rails. Leveraging the asset pipeline seems like the smartest > > >> > > > thing to do moving forward.
> > >> > > > Things I'm interested in figuring out the best approach that gets me > > >> > > > as many of these as possible:
> > >> > > > 1. Headless execution for CI (worst case, one could write a Cuke that > > >> > > > looks at a spec runner page and looks for green) > > >> > > > 2. Dynamic coffee compilation > > >> > > > 3. Picks up new assets/files as they're added (preventing a high > > >> > > > maintenance SpecRunner page) > > >> > > > 4. SpecRunner individually sources each script as opposed to > > >> > > > concatenating them for easier debugging. > > >> > > > 5. RSpec integration would be nifty
> > >> > > > I doubt the official jasmine gem is immediately headed in this > > >> > > > direction. The asset pipeline represents such a major break from the > > >> > > > past that it would be difficult to maintain BC. (related:
> > >> > > > Maybe a new gem to address these and other niceties is called for. I > > >> > > > never thought I'd expect my Jasmine workflow on Java projects would > > >> > > > feel tighter than on Rails. I'm suspicious enough of that conclusion > > >> > > > that I'm willing to bet I'm just ignorant of a better way to do it.
> > >> > > > Thoughts?
> > >> > > > -Justin
> > >> > > > On Jun 25, 5:41 am, Brad Phelan <bradphe...@xtargets.com> wrote: > > >> > > > > Hi Chris,
> > >> > > > > I've put a gem together that I think partially solves what you need.
> > >> > > > > I've got jasmin working with the Rails 3.1 and the asset pipeline and > > >> > > > it's > > >> > > > > possible > > >> > > > > to pull assets into the specs that are gem packaged.
> > >> > > > > Perhaps if the features are not quite what you need you could use it > > >> > as a > > >> > > > > starting point. > > >> > > > > I only threw it together yesterday after getting frustrated with the > > >> > > > current > > >> > > > > jasmine gem.
> Yep I found that if I specified my files individually then it worked fine. It was the glob syntax that failed.
> ------
> Kevin Fitzpatrick
> @kfitzpatrick
> 267.254.6225
> On Sep 30, 2011, at 11:28 AM, Aaron McLeod <sircoolgu...@gmail.com> wrote:
> > Hmm that's odd. Mine is essentially the same. Only different being is i specify the files i need in a particular order cause of dependencies. Here's mine:http://pastie.org/2618361
> > On Wed, Sep 28, 2011 at 8:45 PM, Kevin Fitzpatrick <ke...@pivotalsf.com> wrote:
> > I just tried this out with this jasmine.yml:
> > asset_pipeline_paths:
> > - app/assets
> > - spec/javascripts
> > --------------------------------------------------------------------------- -------------
> > ... and it worked fine for all JS files.
> > When I changed the src files to
> > --------------------------------------------------------------------------- -------------
> > src_files:
> > - app/assets/**/*.js
> > - app/assets/**/*.js.coffee
> > --------------------------------------------------------------------------- -------------
> > The server starts, but hangs when I refresh the browser.
> > Any ideas? I've been digging through the source, but I can't seem to
> > find where the trouble starts.
> > Thanks!
> > - K
> > On Sep 10, 10:37 am, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> > > I spent a few hours this morning adding extremely basic asset pipeline
> > > support. The changes are pushed to the 1.2.rc1 branch of jasmine-gem
> > > (http://github.com/pivotal/jasmine-gem).
> > > Essentially the jasmine.yml file now takes asset_pipeline_paths, each
> > > path you pass here will be mapped through the Sprockets asset
> > > pipeline. We have a bit of a 'hack' in order to permit running files
> > > in the spec directory through Sprockets -- if one of your
> > > asset_pipeline_paths matches your spec_dir, we'll assume you want to
> > > use Sprockets for specs (there's a long story about why the spec dir
> > > gets mapped as __spec__ inside of relative to root, something we might
> > > re-examine in Jasmine 2).
> > > Files passed in will now have any Sprocket compatible engine
> > > extensions stripped off so that we correctly request them from
> > > Sprockets -- ie, app/assets/my_file.js.coffee will be requested by
> > > Jasmine as /app/assets/my_file.js.
> > > I believe Jasmine should do the right thing if you hand it scss files
> > > in your stylesheets and coffee files in your helpers, but I haven't
> > > yet tested it.
> > > This is a pretty minimal spike, so there may be other issues; hoping
> > > this meets the 80% case for most people -- please feel free to offer
> > > your feedback!
> > > Thanks!
> > > Rajan
> > > PS:
> > > Here's a sample configuration file to use coffeescript for your src and specs:
> > > # src_dir
> > > #
> > > # Source directory path. Your src_files must be returned relative to
> > > this path. Will use root if left blank.
> > > # Default: project root
> > > #
> > > # EXAMPLE:
> > > #
> > > # src_dir: public
> > > #
> > > src_dir:
> > > # spec_dir
> > > #
> > > # Spec directory path. Your spec_files must be returned relative to this path.
> > > # Default: spec/javascripts
> > > #
> > > # EXAMPLE:
> > > #
> > > # spec_dir: spec/javascripts
> > > #
> > > spec_dir: spec/javascripts
> > > # asset_pipeline_paths
> > > #
> > > # Paths you would like to be served by the Sprockets asset pipeline.
> > > #
> > > # If you include your spec_dir (eg: - spec/javascripts ) here,
> > > # Jasmine will use the Sprockets asset pipeline to build your spec files.
> > > #
> > > # Default: []
> > > #
> > > # EXAMPLE:
> > > # asset_pipeline_paths:
> > > # - app/assets
> > > # - spec/javascripts
> > > asset_pipeline_paths:
> > > - app/assets
> > > - spec/javascriptsOn Sun, Sep 4, 2011 at 6:06 PM, Colin Jack <colin.j...@gmail.com> wrote:
> > > >> We are gearing up to take on the challenges of working with 3.1 and
> > > >> stuff like RequireJS
> > > > Sounds great, I'd definitely be interested in trying out/using this
> > > > functionality when it exists.
> > > > Thanks,
> > > > Colin
> > > > On Aug 27, 3:13 pm, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> > > >> Awesome! We are gearing up to take on the challenges of working with 3.1 and
> > > >> stuff like RequireJS, so these sorts of things will be great examples for us
> > > >> to follow. I am hoping we have a solution for Rails 3.1 folks before it gets
> > > >> officially released.
> > > >> On Fri, Aug 26, 2011 at 12:46 PM, Justin Searls <sea...@gmail.com> wrote:
> > > >> > In the meantime I had a pretty good experience with jasmine-headless-
> > > >> > webkit last week. I'm looking at adding a simple custom spec runner
> > > >> > ERB template that loads in the same stuff the jasmine.yml calls for so
> > > >> > you can also load the specs in browser when you want to. (Not to work
> > > >> > around or circumvent your great work, Rajan; just in the interest in
> > > >> > getting a good working solution for 3.1 today).
> > > >> > On Aug 23, 10:10 am, Rajan Agaskar <ra...@pivotallabs.com> wrote:
> > > >> > > I think 2 and 3 (and whatever work we need to actually use the pipeline)
> > > >> > are
> > > >> > > probably near-term priorities for the Jasmine gem, but I think you're
> > > >> > > correct in that it's going to take awhile to get there. We haven't been
> > > >> > > great about timely acceptance of pull requests (we're trying to get that
> > > >> > > better), but I'd love to see patches go into jasmine-gem rather than
> > > >> > > fragmented into another Rails 3.1-only gem.
> > > >> > > It's possible we're eventually going to be pushed into splitting up the
> > > >> > gem
> > > >> > > regardless. The original intent of having a single gem that meets many
> > > >> > > purposes was so people could simply type `gem install jasmine` and get
> > > >> > > going; as Rails 3.1 changes many things about how JS works and Rails 2
> > > >> > falls
> > > >> > > farther behind Rails 3 this is getting tricky to keep in place.
> > > >> > > On Fri, Aug 19, 2011 at 9:50 AM, Justin Searls <sea...@gmail.com> wrote:
> > > >> > > > I'm reviving this thread after independently playing with Chris's demo
> > > >> > > > & also Brad's gem.
> > > >> > > > Has there been any movement on this recently? I'm really interested to
> > > >> > > > learn what the current options are out there for integrating Jasmine
> > > >> > > > with Rails. Leveraging the asset pipeline seems like the smartest
> > > >> > > > thing to do moving forward.
> > > >> > > > Things I'm interested in figuring out the best approach that gets me
> > > >> > > > as many of these as possible:
> > > >> > > > 1. Headless execution for CI (worst case, one could write a Cuke that
> > > >> > > > looks at a spec runner page and looks for green)
> > > >> > > > 2. Dynamic coffee compilation
> > > >> > > > 3. Picks up new assets/files as they're added (preventing a high
> > > >> > > > maintenance SpecRunner page)
> > > >> > > > 4. SpecRunner individually sources each script as opposed to
> > > >> > > > concatenating them for easier debugging.
> > > >> > > > 5. RSpec integration would be nifty
> > > >> > > > I doubt the official jasmine gem is immediately headed in this
> > > >> > > > direction. The asset pipeline represents such a major break from the
> > > >> > > > past that it would be difficult to maintain BC. (related:
