3.4.0 - random ignored for jasmine:server

[himdel]

When running the tests manually via rake environment jasmine, the setting of random: false in jasmine.yml is completely ignored.

It seems that jasmine only uses this to generate the url for jasmine:ci.

Which means you can get local failures even if everything is allright on travis :(.

(This can be worked around by opening localhost:8888/?random=false instead of just localhost:8888.)

[slackersoft]

Currently, the random setting is passed to Jasmine via the browser url, so there isn't really a good way to pass it when loading the page manually.

[himdel]

True, but jasmine gem is already runing a webserver..

What about adding an endpoint that would serve jasmine.yml contents as JSON, and have the page read the option from there instead?

[himdel]

As an experiment, tried adding this to my jasmine_helper.rb...

class JasmineConfig
  def initialize(file)
    @config = YAML.load_file(file)
  end

  def call(env)
    [200, {"Content-Type" => "application/json"}, [@config.to_json]]
  end
end

Jasmine.configure do |config|
  # serve config as json
  config.add_rack_path('/jasmine_config.json', -> { JasmineConfig.new(File.join(__dir__, 'jasmine.yml')) })
end

and voila, I can GET the config from localhost:8888/jasmine_config.json when running jasmine :)

[slackersoft]

To be a bit more clear... Currently the code running in the browser is only served by the Jasmine Gem, but is actually provided by Jasmine-Core. Simply allowing another file to be loaded from the existing server isn't enough to allow anything to be loaded out of it. Changes would have to be made to how Jasmine-Core presents html to be loaded and executed in the browser to look in some place other than the query string.

This style of issue has been on the radar for a while, but we haven't really come up with a good way to allow the rack server to inject code to change the configuration of the Jasmine environment being loaded on the page.

If you have any ideas on how to split up boot.js or inject other scripts from Jasmine-Gem into the page such that they run before the query string configuration, but after a Jasmine Env has been created, I would be happy to review a pull request.

[himdel]

Hey, sure, I'll give that a go :)

Have there been any discussion I can read about what kind of solutions were rejected already and why?

Because I'm seeing several options:

• make boot.js just fetch a config url, wait for it, and do the initialization once it loads, falling back to default if missing
  • would need something like that jasmine_config.json route on this side
  • and a change to boot.js on jasmine side (fetch(config_url).then(use_it).catch(defaults).then(the rest of initialization))
• make jasmine gem transform boot.js to already contain the config, while serving it
  • no need for changes on jasmine side
  • a bit of a hack on the gem side perhaps, in that serving modified versions of jasmine files is nonintuitive
• make jasmine gem override jasmine's assets and provide its own index.html to inject extra files
  • no changes on jasmine side
  • extra maintenance burden on the gem side
• leverage pupetteer to inject the script in chrome headless
  • would not support phantomjs

Thanks!

[slackersoft]

boot.js is also used in the standalone Jasmine for folks who don't want to install any of the other runners, so I don't think we can justify having it actually try to fetch another file to get configuration options.

I agree that transforming boot.js would be finicky and probably not the direction we want to go.

As I dig into this problem again, Jasmine-Gem actually does provide its own index.html which can be tweaked to allow extra scripts to be loaded. The trick here is that the query params (as handled in boot.js) should really take precedence over anything configured in your config.yml. The problem here is that boot.js both initializes the Jasmine environment (the thing that gets configured) and configures the environment from the query string. This is the thing that would need to be split in some fashion (or at least made configurable somehow) in order to get this functionality to work intuitively for users.

I'm not sure that using puppeteer would solve this problem, since it controls the browser which is not being used if you're just starting a server.