Rails with the asset pipeline setup

With Rails 3.1 and later you can write your Jasmine specs in addition to JavaScript with CoffeeScript, fully integrated
into the Rails asset pipeline. 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. Step by step instructions on configuring this are below.

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::alwaysdo...end

Server options

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

server::jasmine_gem# Jasmine server to use, either :auto, :none,# :webrick, :mongrel, :thin, :unicorn, :jasmine_gem, :puma# default: :autoserver_env::test# Jasmine server Rails environment to set,# e.g. :development or :test# default: RAILS_ENV is exists, otherwise :developmentserver_timeout:30# The number of seconds to wait for the Jasmine spec server# default: 15port:8888# Jasmine server port to use. Note that some ports (e.g. 6665) won't work.# This is due to the fact that Webkit considers them unsafe.# default: a random, free server portphantomjs_bin:'~/bin/phantomjs'# Path to phantomjs.# default: auto-detect 'phantomjs'timeout:20# The time in seconds to wait for the spec runner to finish.# default: 10rackup_config:'spec/dummy/config.ru'# Path to rackup config file (i.e. for webrick, mongrel, thin, unicorn, puma).# default: ./config.ru# This option is useful when using guard-jasmine in a mountable engine# and the config.ru is within the dummy app

If you're setting the :server option to :none or need to access your specs on a other host than localhost, you can
supply the Jasmine runner url manually:

You may want to have also a fixed port instead of the random generated one.

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.

Use a custom server

If you supply an unknown server name as the :server option, then Guard::Jasmine will execute
a rake task with the given server name as task in a child process. For example, if you configure
server: 'start_my_server', then the command rake start_my_server will be executed and
you have to make sure the server starts on the port that you can get from the JASMINE_PORT
environment variable.

Spec runner options

spec_dir:'app/spec'# Directory with the Jasmine specs.# default: 'spec/javascripts'clean:false# Clean the spec list by only keep Jasmine specs within the project.# default: trueall_on_start:false# Run all suites on start.# default: truekeep_failed:false# Keep failed suites and add them to the next run again.# default: trueall_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.

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.

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:

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 :errors option is partially working when using at least PhantomJS version 1.5. Please see
Issue #166 for the actual status of retreiving the JavaScript
stack trace.

Overwrite options when running all specs

You may want to have different options when the spec runner runs all specs. You can specify the :run_all option
as a Hash that contains any valid runner option and will overwrite the general options.

run_all:{specdoc::never}# Run all options,# Takes any valid option# default: {}

Console logs

The :console options adds captured console logs from the spec runner and adds them to the specdoc. Guard:Jasmine
contains its own minimalistic console implementation. The following console methods are supported:

console.log

console.info

console.warn

console.error

console.debug

The difference for each of this log methods is simply a prefix that is added to the log statement. The log also
supports the common format placeholders:

%s

%i, %d

%f

%o

You can further customize the log output by implement one of these methods:

toString() - must return a string that describes the object

toJSON() - must return an object that is used instead of the actual object.

In addition, the console can log jQuery collections and outputs the HTML representation of the element by using the
jQuery html() method.

Instrumentation

Istanbul needs to instrument the implementation files so that the execution path can be detected. Guard::Jasmine comes
with a tilt template that generates instrumented implementation files when using in the asset pipeline. If you do not
use asset pipeline, than you need to instrument your files on your own, either manually (basic example: istanbul instrument --output instrumented_scripts scripts) or by using something like
Guard::Process. You can get more information about the
instrumentation with istanbul help instrument. You'll also need to update your :spec_dir or jasmine.yml/src_dir settings to point Guard::Jasmine to these instrumented source files.

Important: You need to clear the asset cache when you change this setting, so that already compiled assets will be
recompiled. Just use the Sprockets supplied Rake task:

$ rakeassets:clean

Check coverage

By default Guard::Jasmine just outputs the coverage when enable without any effect on the spec run result. You can
make Guard::Jasmine fail the spec run when a given threshold is not met. You can set the following thresholds:

The :coverage_summary options disables the detailed file based coverage report by a small summary coverage report.

Both of these results are more useful if they are run against the coverage data from a full spec run, so it's strongly
advised to enable the :all_on_start option.

With Jasmine in the asset pipeline all instrumented implementation files are available in the runtime and when you
execute a partial spec run it reports a lower coverage for the excluded files, since their associated specs aren't run.
Guard::Jasmine tries to work around this by merge only the coverage data for the changed files (Istanbul knows the file
name in opposite to Jasmine).

Jenkins CI integration

You can use the Cobertura format to bring coverage support to Jenkins CI, even that Guard::Jasmine has no built in
support for it. The trick is to post-process the coverage data with istanbul after the spec run:

desc"Run all JavaScript specs with Istanbul"task:jscov=>:environmentdo# Run Jasmine tests with code coverage on and generate Jenkins-compatible Jasmine code coverage report file.# Must run assets:clean first to force re-compilation.# Make sure to fail this task if there are unit test failures.# For some reason does not work if run as separate exec's, so combine into one.exec('rake assets:clean; guard-jasmine --coverage --coverage-html --coverage-summary; \
code=$?; if [ $code != "0" ]; then exit $code; fi; istanbul report cobertura')end

System notifications options

These options affects what system notifications are shown after a spec run:

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.

Tip: It's highly recommended the have a server timeout of at least 60 seconds, since the performance of the Travis VMs seems to
vary quite a bit; sometimes the Jasmine server starts in 5 seconds, sometimes it takes as long as 50 seconds.

How to test a Rails engine with Jasmine Gem

When building an engine, your code lives at the root but the dummy Rails app is in another folder (like test/dummy or spec/dummy).

How to file an issue

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 have study the README carefully.

Make sure you run Guard with bundle exec first.

Add debug information to the issue by running Guard with debug: true set in the options.

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

Open Commit Bit

Guard has an open commit bit policy: Anyone with an accepted pull request gets added as a repository collaborator.
Please try to follow these simple rules:

Commit directly onto the master branch only for typos, improvements to the readme and documentation (please add
[ci skip] to the commit message).

Create a feature branch and open a pull-request early for any new features to get feedback.

Make sure you adhere to the general pull request rules above.

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:

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