jasmine_config.rb is not read in Jasmine 1.3.1

[ebarendt]

Commit 76b7cde removes the ability to run any code before executing the specs (run_specs.rb). The documentation still refers to this file. What's the replacement for this behavior? Was it removed accidentally.

[ctucker]

Just hit the same issue. There doesn't appear to be any way currently to set, for example, the selenium browser in jasmine:ci task.

[ragaskar]

Support for jasmine_config.rb was removed intentionally because we don't want the gem to look for a 'magic' file on your filesystem (and we also really want to discourage people monkey-patching Jasmine::Config as a way of changing Config behavior -- the hope was with the refactor that config supports everything end users were likely to need).

What was unintentional was doing such a bad job of documenting/announcing these changes.

After Jasmine has been required, there is a Configuration singleton you can access in the following manner:

Jasmine.configure do |config|
  #ex. set browser for selenium from ENV
  config.browser = ENV["JASMINE_BROWSER"]
end

What hasn't really been figured out yet is where the best place for this configuration to happen. If you have a Rails app, you may just be able to add an initializer that does this because we should be booting the Rails env (although there might be some dependency order issues here that force you to require 'jasmine' yourself). More than happy to take suggestions here.

If there's other needs that the jasmine_config.rb file was fulfilling that you don't think you'll be able to do with the config block or an initializer, please let us know -- perhaps the config needs to also support arbitrary pre-server startup callbacks, although we want to keep responsibilities generic and at a minimum.

FWIW, many (although not all) ENV variables have been pulled. We don't want to manage "magic" env variables either, it will be the end users responsibility to use ENV vars over simple strings if they have the need.

[ebarendt]

We use vcr/webmock to intercept http connections. It works great except we also use a selenium build grid to run the tests, so that is one http connection that has to be allowed to work. Our jasmine_config.rb file has the VCR configuration necessary to allow that connection. I don't think an initializer will work in this case because we don't want that jasmine-only configuration alongside the rest of the application configuration. I suppose it could go into the environments/test.rb file?

[ctucker]

Looking at the code in run_specs.rb, loaded by the jasmine:ci task, I don't see where any extra config could be loaded prior to creating the selenium driver. In particular, the config is loaded and used to build the driver thus:

Jasmine.load_configuration_from_yaml

config = Jasmine.config

server = Jasmine::Server.new(config.port, Jasmine::Application.app(config))
driver = Jasmine::SeleniumDriver.new(config.browser, "#{config.host}:#{config.port}/")

There's no opportunity between the loading of the yaml, the assignment of the config, and the creation of the driver to inject any additional configuration options.

The only option I can see is to write my own independent rake task for CI; not a huge burden, but more than seems necessary.

It seems like this may be a slightly different problem to the one @ebarendt is experiencing, so apologies if this is turning into a bit of a thread hijack.

[ragaskar]

Right; no, i think this is a similar problem and I don't mind keeping the discussion in this thread. This is a tricky problem to solve if we want to avoid require-ing a magic file (which right now, I think we'd like to continue doing). The run_specs file essentially runs in a 'new' environment where you don't really have any hooks to fire off a config block. I'm happy to take suggestions here.

In the near future we're hoping to eliminate the need for rspec entirely (we're mostly using it for formatting/exit codes), so this should be less of an issue (since we won't shell out to rspec).

[ebarendt]

FWIW, we need to run rspec before jasmine anyway to create our test fixtures.

[ebarendt]

I don't feel like jasmine_config.rb is a magic file if it's documented. Right now, it's mentioned, but nothing else about it. The environment variables, yeah - those should probably live in jasmine_config.rb too.

Or how about mirroring Rails:
spec/javascripts/config or or config/initializers

[ctucker]

You could avoid a magic file by having the user modify the jasmine.rake file that loads jasmine/tasks/jasmine.rake and creating some kind of a config override object that will then be in scope for the load (or loading something locally). You could also do a conditional load of a file by default there, which would at least limit the magic to something in the control of the application user rather than the gem author (i.e. the application user could modify the generated rakefile to point at whatever file(s) are needed). I think I'd favor this approach.

It might even make sense for this file to perform the YAML load, as it would the open to door to managing config in alternative manners (e.g. in pure ruby or JSON) where that makes sense. Then you'd have something that looked like:

# lib/tasks/jasmine.rake
begin
  require 'jasmine'
  load 'spec/javascripts/support/jasmine_config.rb'
  load 'jasmine/tasks/jasmine.rake'
rescue LoadError
  task :jasmine do
    abort "Jasmine is not available. In order to run jasmine, you must: (sudo) gem install jasmine"
  end
end

# spec/javascripts/support/jasmine_config.rb
Jasmine.load_configuration_from_yaml
Jasmine.config do |config|
    # Modify config as desired in here
end

and within run_specs.rb you'd access Jasmine.config as you do at present.

If you don't pull the YAML load out, you'd simply have to make sure that the Jasmine.config method (or a suitably named alternative) stash away the config information supplied in a way it can be picked up again by the run_specs.rb script and applied after the YAML load. The class-level/static nature of that whole system makes this a little harder than it need be but is plenty doable.

[ragaskar]

I may be too harsh on jasmine_config.rb because early on we were suggesting that users configure jasmine by overriding the Jasmine::Config object, which is a Very Bad Idea™. I suppose I might feel less hateful towards it if we called it jasmine_helper.rb or the like, and perhaps that's simpler (and really, more sensible) solution here. I'll have to give it some thought.

---

ctucker, thanks for the suggestion. I'm currently thinking a Rake task dependency might be a good way to permit users to run arbitrary code, but there's a couple issues we face here.

1. IIRC the run_specs file is essentially called from shell command executed inside of a Rake task (and maybe this is just something we need to fix) -- this means the Ruby process you knew and loved when your Rake task was loaded is not present at the point where you're calling Jasmine.config inside of run specs; ie, I don't believe any of the code you load inside of a rake dependency will execute in the environment that's actually starting the jasmine server for the jasmine:ci task.

2. I want to keep as much Jasmine wiring out of end-user-accessible files as possibile. We did this early on and it made the upgrade path really difficult, as whenever we needed to change jasmine.rake there was pain in a) informing end users that they needed to re-install jasmine support files, and b) when they reinstalled, worrying about whether or not we are potentially blowing away custom modifications made by the end user -- that's why we now use a railtie to load jasmine-related tasks.

---

Let me also briefly talk about why eliminating rspec as a dependency is a goal: outside of Rails, one of the biggest pain points in jasmine-gem maintenance is the rspec formatter, because it needs to stay current with rspec changes (and because we're maintaining backwards compatibility with rspec 1 and rails 2, but that's a whole other tangle).

The problem isn't really that users don't have rspec installed, rather it's that they do, and they want it to be current -- if Jasmine is broken on a new version of rspec, it's usually an on-fire thing that end-users want a fix for pretty quickly. My current belief is that the jasmine-gem should be agnostic about how results are formatted. I'd like to provide a sensible default that works for most CI systems in place (probably something that dumps plain-text w/ an exit code and then also writes out a jUnit XML file) and then allow end users to add on jasmine formatters as desired, just like rspec. Then someone else who understands rspec a little better than I do can maintain the rspec-jasmine bridge. ;)

Lastly, the rspec formatter is also just plain weird -- we've technically already ran a test suite, and then we take the results of that and build up a new one in memory, with bodies that essentially reflect the pass/fail of the current test suite results, and then execute it. We're running two test suites to show you results, when we could just say, hey, here are the results. At the time the jasmine-gem was written, there were some benefits to running the results through rspec, but I'm not sure those are quite as prominent.

[ragaskar]

Jasmine HEAD should now load spec/support/jasmine_helper.rb after the jasmine.yml settings are parsed -- this should provide a convenient place to add a Jasmine.configure block. I think this should meet most needs that were formally provided by jasmine_config.rb.

You can also configure the path of this file in jasmine.yml if desired.

[doitian]

I load jasmine_config.rb in a rake task and add it as a dependency of 'jasmine:require':

# lib/tasks/jasmine_config.rake
namespace :jasmine do
  task :config do
    load Rails.root.join('spec/javascripts/support/jasmine_config.rb')
  end
end

task "jasmine:require" => ["jasmine:config"]

[subimage]

A bit late to the game here, but I'm having issues transitioning to this new way of configuring things. I'm still stuck on Rails 2.3.x and I'm using Jammit to package my assets. Before, I was using the (evil?) method of monkey patching Jasmine::Config to do the following...

Jasmine.configure do |config|
  Jammit.reload!
  Jammit.package!({ :config_path => Rails.root.join("config", "assets_test.yml")})
end

This loads my JST files, which are necessary for my tests.

Sadly with the new jasmine_helper.rb file I get Ruby complaining: 'uninitialized constant Jammit' ...which looks to me like the Rails env isn't loaded - because I have the gem included via bundler.

Can anyone give me a pointer to get me on track again here?