Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
The Swiss Army knife for automated Jasmine specs in your console.
Ruby JavaScript CoffeeScript

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.
bin
lib/guard
resources
spec
.gitignore
.rvmrc
.travis.yml
.yardopts
Gemfile
Guardfile
LICENSE
README.md
Rakefile
guard-jasmine.gemspec

README.md

Guard::Jasmine Build Status

Guard::Jasmine automatically tests your Jasmine specs on Rails when files are modified.

Tested on MRI Ruby 1.8.7, 1.9.2, 1.9.3, REE and the latest versions of JRuby and Rubinius.

If you have any questions please join us on our Google group or on #guard (irc.freenode.net).

Highlights

  • Continuous testing based on file modifications by Guard, manifold configuration by writing rules with RegExp and Ruby.

  • Fast headless testing on PhantomJS, a full featured WebKit browser with native support for various web standards: DOM handling, CSS selector, JSON, Canvas, and SVG.

  • Runs the standard Jasmine test runner, so you can use Jasminerice for integrating Jasmine into the Rails 3.1 asset pipeline and write your specs in CoffeeScript.

  • Thor and Rake command line helper for CI server integration.

  • Runs on Mac OS X, Linux and Windows.

Install

Guard and Guard::Jasmine

The simplest way to install Guard is to use Bundler. Please make sure to have Guard installed.

Add Guard::Jasmine to your Gemfile:

group :development, :test do
  gem 'guard-jasmine'
end

Add the default Guard::Jasmine template to your Guardfile by running:

$ guard init jasmine

PhantomJS

You need the PhantomJS browser installed on your system. You can download binaries for Mac OS X and Windows from the PhantomJS download section.

Alternatively you can install Homebrew on Mac OS X and install it with:

$ brew install phantomjs

If you are using Ubuntu 10.10, you can install it with apt:

$ sudo add-apt-repository ppa:jerome-etienne/neoip
$ sudo apt-get update
$ sudo apt-get install phantomjs

You can also build it from source for several other operating systems, please consult the PhantomJS build instructions.

Rails 3.1 setup

With Rails 3.1 you can write your Jasmine specs in addition to JavaScript with CoffeeScript, fully integrated into the Rails 3.1 asset pipeline with Jasminerice. You have full access to your running Rails app, but it's a good practice to fake the server response. Check out the excellent Sinon.JS documentation to learn more about this topic.

Guard::Jasmine will start a Rails Rack server to run your specs.

How it works

Guard Jasmine

  1. Guard is triggered by a file modification.
  2. Guard::Jasmine executes the PhantomJS script.
  3. The PhantomJS script requests the Jasmine test runner via HTTP.
  4. Rails uses the asset pipeline to get the Jasmine runner, the code to be tested and the specs.
  5. The asset pipeline prepares the assets, compiles the CoffeeScripts if necessary.
  6. The asset pipeline has finished to prepare the needed assets.
  7. Rails returns the Jasmine runner HTML.
  8. PhantomJS requests linked assets and runs the Jasmine tests headless.
  9. The PhantomJS script collects the Jasmine runner results and returns a JSON report.
  10. Guard::Jasmine reports the results to the console and system notifications.

Jasminerice

Please read the detailed installation and configuration instructions at Jasminerice.

In short, you add it to your Gemfile:

group :development, :test do
  gem 'jasminerice'
end

And run following from the Terminal:

mkdir -p spec/javascripts
echo -e "#=require application\n#=require_tree ./" > spec/javascripts/spec.js.coffee
echo -e "/*\n * add css using =require application\n */" > spec/javascripts/spec.css

This creates the directory spec/javascripts where your CoffeeScript tests go into. You define the Rails 3.1 asset pipeline manifest in spec/javascripts/spec.js.coffee:

#=require application
#=require_tree ./

It also creates an empty spec/javascripts/spec.css file as it is always requested when running specs.

Now you can access /jasmine url when you start rails server normally.

Rails 2 & Rails 3 setup

With Rails 2 or Rails 3 you can use the Jasmine Gem to configure your Jasmine specs and server the Jasmine runner. You don't have full access to your running Rails app, but it's anyway a good practice to fake the server response. Check out the excellent Sinon.JS documentation to learn more about this topic.

Guard::Jasmine will start a Jasmine Gem Rack server to run your specs.

How it works

Guard Jasmine

  1. Guard is triggered by a file modification.
  2. Guard::Jasmine executes the PhantomJS script.
  3. The PhantomJS script requests the Jasmine test runner via HTTP.
  4. The Jasmine Gem reads your configuration and get the assets.
  5. The Jasmine Gem serves the the code to be tested and the specs.
  6. PhantomJS runs the Jasmine tests headless.
  7. The PhantomJS script collects the Jasmine runner results and returns a JSON report.
  8. Guard::Jasmine reports the results to the console and system notifications.

Jasmine Gem

Please read the detailed installation and configuration instructions at the Jasmine Gem.

In short, you add it to your Gemfile:

group :development, :test do
  gem 'jasmine'
end

and generate the configuration files:

for Rails 3

$ rails g jasmine:install

for Rails 2

$ script/generate jasmine

Now you can configure your spec suite in the Jasmine configuration file specs/javascripts/support/jasmine.yml.

Writing CoffeeScript specs

It is also possible to use CoffeeScript in this setup, by using Guard::CoffeeScript to compile your code and even specs. Just add something like this before Guard::Jasmine:

guard 'coffeescript', :input => 'app/coffeescripts',  :output => 'public/javascripts'
guard 'coffeescript', :input => 'spec/coffeescripts', :output => 'spec/javascripts'

Usage

Please read the Guard usage documentation.

Guardfile

Guard::Jasmine can be adapted to all kind of projects. Please read the Guard documentation for more information about the Guardfile DSL.

guard 'jasmine' do
  watch(%r{app/assets/javascripts/(.+)\.(js\.coffee|js)}) { |m| "spec/javascripts/#{m[1]}_spec.#{m[2]}" }
  watch(%r{spec/javascripts/(.+)_spec\.(js\.coffee|js)})  { |m| "spec/javascripts/#{m[1]}_spec.#{m[2]}" }
  watch(%r{spec/javascripts/spec\.(js\.coffee|js)})       { "spec/javascripts" }
end

Options

There are many options that can customize Guard::Jasmine to your needs. Options are simply supplied as hash when defining the Guard in your Guardfile:

guard 'jasmine', :all_on_start => false, :specdoc => :always do
  ...
end

General options

The general options configures the environment that is needed to run Guard::Jasmine:

:server => :jasmine_gem                       # Jasmine server to use, either :auto, :none,
                                              # :webrick, :mongrel, :thin, :jasmine_gem
                                              # default: :auto

:server_env => :test                          # Jasmine server Rails environment to set,
                                              # e.g. :development or :test
                                              # default: :development

:port => 9292                                 # Jasmine server port to use.
                                              # default: 8888

:phantomjs_bin => '~/bin/phantomjs'           # Path to phantomjs.
                                              # default: auto-detect 'phantomjs'

:timeout => 20000                             # The time in ms to wait for the spec runner to finish.
                                              # default: 10000

If you're setting the :server option to :none, you can supply the Jasmine runner url manually:

:jasmine_url => 'http://192.168.1.5/jasmine'  # URL where Jasmine is served.
                                              # default: http://127.0.0.1:8888/jasmine

:clean => false                               # Clean the spec list by only keep Jasmine specs within the project.
                                              # default: true

Detecting the server with the auto option does only detect the jasmine gem or webrick. If you want to use mongrel or thins, you have to set it explicit in the server option.

The reason why the Server environment is set to development by default is that in development mode the asset pipeline doesn't concatenate the JavaScripts and you'll see the line number in the real file, instead of a ridiculous high line number in a single, very large JavaScript.

In general you want to leave the :clean flag on, which ensures that only Jasmine specs (files ending with _spec.js, _spec.coffee and _spec.js.coffee inside your project are passed to the runner. If you have a custom project structure or spec naming convention, you can set :clean to false to skip that file filter.

Spec runner options

The spec runner options configures the behavior driven development (or BDD) cycle:

:all_on_start => false                        # Run all suites on start.
                                              # default: true

:keep_failed => false                         # Keep failed suites and add them to the next run again.
                                              # default: true

:all_after_pass => false                      # Run all suites after a suite has passed again
                                              # after failing.
                                              # default: true

The :keep_failed failed option remembers failed suites and not failed specs. The reason for this decision is to avoid additional round trip time to request the Jasmine test runner for each single spec, which is mostly more expensive than running a whole suite.

Specdoc options

Guard::Jasmine can generate an RSpec like specdoc in the console after running the specs and you can set when it will be shown in the console:

:specdoc => :always                           # Specdoc output options,
                                              # either :always, :never or :failure
                                              # default: :failure

:focus => false                               # Specdoc focus to hide successful specs when
                                              # at least one spec fails.
                                              # default: true

:console => :always                           # Console.log output options,
                                              # either :always, :never or :failure
                                              # default: :failure

With the option set to :always, the specdoc is shown with and without errors in your spec, whereas on with the option set to :never, there is no output at all, instead just a summary of the spec run is shown. The default option :failure shows the specdoc when at least one spec failed.

When :focus is enabled, only the failing specs are shown in the specdoc when at least one spec is failing.

The :console options adds captured console logs from the spec runner and adds them to the specdoc. Please note that PhantomJS only support capturing of console.log, so the other log functions like debug, warn, info and error are missing. Please vote on Issue 232 if you like to see support for more console methods coming to PhantomJS.

Another restriction on console logging is that currently only the first log parameter is passed. So instead of writing

console.log('Debug of %o with %s', object, string)

your should write

console.log('Debug of ' + object.toString() + ' width ' + string)

You can also give your vote on Issue 36 to see support for multiple console arguments.

System notifications options

These options affects what system notifications (growl, libnotify or notifu) are shown after a spec run:

:notifications => false                       # Show success and error notifications.
                                              # default: true

:hide_success => true                         # Disable successful spec run notification.
                                              # default: false

:max_error_notify => 5                        # Maximum error notifications to show.
                                              # default: 3

Mapping file changes to the spec filter

Jasmine doesn't know anything about your test files, it only knows the name of your specs that you specify in the describe function. When a file change is detected, Guard::Jasmine extracts the first spec name of the file and uses that spec description as spec filter.

So if you want to have a precise spec detection, you should:

  • Use only one top-level description per spec file.
  • Make each top-level description unique.

To get a feeling how your naming strategy works, play with the web based Jasmine runner and modify the spec query parameter.

Guard::Jasmine outside of Guard

Thor command line utility

Guard::Jasmine includes a little command line utility to run your specs once and output the specdoc to the console.

$ guard-jasmine

You can get help on the available options with the help task:

$ guard-jasmine help spec

Usage:
  guard-jasmine spec

Options:
  -s, [--server=SERVER]          # Server to start, either `auto`, `none`, `webrick`, `mongrel`,
                                 # `thin`, `jasmine_gem`
                                 # Default: auto
  -p, [--port=N]                 # Server port to use
                                 # Default: 8888
  -u, [--url=URL]                # The url of the Jasmine test runner
                                 # Default: http://localhost:8888/jasmine
  -b, [--bin=BIN]                # The location of the PhantomJS binary
                                 # Default: /usr/local/bin/phantomjs
  -t, [--timeout=N]              # The maximum time in milliseconds to wait
                                 # for the spec runner to finish
                                 # Default: 10000
  -c, [--console=CONSOLE]        # Whether to show console.log statements in the spec runner,
                                 # either `always`, `never` or `failure`
                                 # Default: failure
  -e, [--server-env=SERVER_ENV]  # The server environment to use, for example `development`, `test`
                                 # Default: test

Run the Jasmine spec runner

By default all specs are run, but you can supply multiple paths to your specs to run only a subset:

$ guard-jasmine spec/javascripts/a_spec.js.coffee spec/javascripts/another_spec.js.coffee

Rake task integration

Guard::Jasmine provides a Rake task wrapper around the Thor command line utility. Simply create a JasmineTask within your Rakefile:

require 'guard/jasmine/task'
Guard::JasmineTask.new

You can configure the CLI options either by providing the options as parameter or use a block:

require 'guard/jasmine/task'

Guard::JasmineTask.new do |task|
  task.options = '-t 15 -e test'
end

Guard::JasmineTask.new(:jasmine_no_server, '-s none')

Travis CI integration

With the given guard-jasmine script you're able to configure Travis CI to run Guard::Jasmine. Simply use the script setting in your .travis.yml:

before_script:
  - "export DISPLAY=:99.0"
  - "sh -e /etc/init.d/xvfb start"
script: 'bundle exec guard-jasmine'

You can also run your Guard::Jasmine specs after your specs that are ran with rake by using after_script:

before_script:
  - "export DISPLAY=:99.0"
  - "sh -e /etc/init.d/xvfb start"
script: 'rake spec'
after_script: 'bundle exec guard-jasmine'

Alternatives

There are many ways to get your Jasmine specs run within a headless environment. If Guard::Jasmine isn't for you, I recommend to check out these other brilliant Jasmine runners:

Guards

Standalone

  • Evergreen, runs CoffeeScript specs headless, but has no continuous testing support.
  • Jezebel a Node.js REPL and continuous test runner for Jessie, a Node runner for Jasmine, but has no full featured browser environment.

Issues

You can report issues and feature requests to GitHub Issues. Try to figure out where the issue belongs to: Is it an issue with Guard itself or with Guard::Jasmine? Please don't ask question in the issue tracker, instead join us in our Google group or on #guard (irc.freenode.net).

When you file an issue, please try to follow to these simple rules if applicable:

  • Make sure you run Guard with bundle exec first.
  • Add debug information to the issue by running Guard with the --verbose option.
  • Add your Guardfile and Gemfile to the issue.
  • Make sure that the issue is reproducible with your description.

Development

Pull requests are very welcome! Please try to follow these simple rules if applicable:

  • Please create a topic branch for every separate change you make.
  • Make sure your patches are well tested.
  • Update the Yard documentation.
  • Update the README.
  • Update the CHANGELOG for noteworthy changes.
  • Please do not change the version number.

For questions please join us in our Google group or on #guard (irc.freenode.net).

The guard-jasmine-debug executable

This Guard comes with a small executable guard-jasmine-debug that can be used to run the Jasmine test runner on PhantomJS and see the JSON result that gets evaluated by Guard::Jasmine. This comes handy when there is an issue with your specs and you want to see the output of the PhantomJS script.

$ guard-jasmine-debug

The only argument that the script takes is the URL to the Jasmine runner, which defaults to http://127.0.0.1:3000/Jasmine. So you can for example just run a subset of the specs by changing the URL:

$ guard-jasmine-debug http://127.0.0.1:3000/Jasmine?spec=YourSpec

Contributors

See the the GitHub list of contributors.

Acknowledgment

  • Ariya Hidayat for PhantomJS, a powerful headless WebKit browser.
  • Brad Phelan for Jasminerice, an elegant solution for Jasmine in the Rails 3.1 asset pipeline.
  • Pivotal Labs for their beautiful Jasmine BDD testing framework that makes JavaScript testing fun.
  • Jeremy Ashkenas for CoffeeScript, that little language that compiles into JavaScript and makes me enjoy the front-end.
  • The Guard Team for giving us such a nice piece of software that is so easy to extend, one has to make a plugin for it!
  • All the authors of the numerous Guards available for making the Guard ecosystem so much growing and comprehensive.

License

(The MIT License)

Copyright (c) 2011-2012 Michael Kessler

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Something went wrong with that request. Please try again.