teaspoon 0.7.9 → 0.8.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 8cef218e8022c1570a522f1d4a1d7f7f8e2a367f
-  data.tar.gz: ca33470c138fad431468907cb7e8c0961cd6d739
+  metadata.gz: 8fbbf5295bc786b2056c1863d366a253f191e420
+  data.tar.gz: 43b86be934c3ebe643d667f3569e3b2fbee76232
 SHA512:
-  metadata.gz: e3d0cfcf706cf47bff2d7bb0b727159ba2e77dfa02dfaca7199ff68bae1583fd9d46ef331340c2cfc0fcefd9c3138892abdbf01990ff5db0e6cc45e266d5776a
-  data.tar.gz: ad850647cd5f11675c4bb3995326a4bb31eb40bc0b7e1f0b14d6438786f098272aee1858bafc65294a448bf6467d3b46763099123d21c9ea7eff55a218e55e12
+  metadata.gz: d2ccba66f0a0d524924cdf6999e3d785d80c46b3e6c704b066de0900641c576a90aabda5e52c6ede4440148f0806064dfca54a6e1b2ee2f42d997fee1f1078d5
+  data.tar.gz: dfa0de920af9e2b437498f08e39afdd449a69297c1cb9179e00f8c7bdbd7dfb76b358a3550f32ae93991b1e6bb2a069436a6159b796f6cfa7f23ff1a62af0923

data/README.md

@@ -1,26 +1,49 @@
-### ![Logo by Morgan Keys](https://raw.github.com/modeset/teaspoon/master/screenshots/logo.png)
+Teaspoon
+========
 
-[![Gem Version](https://badge.fury.io/rb/teaspoon.png)](http://badge.fury.io/rb/teaspoon)
-[![Build Status](https://travis-ci.org/modeset/teaspoon.png)](https://travis-ci.org/modeset/teaspoon)
-[![Code Climate](https://codeclimate.com/github/modeset/teaspoon.png)](https://codeclimate.com/github/modeset/teaspoon)
+[![Gem Version](https://img.shields.io/gem/v/teaspoon.svg)](http://badge.fury.io/rb/teaspoon)
+[![Dependency Status](https://img.shields.io/gemnasium/modeset/teaspoon.svg)](https://gemnasium.com/modeset/teaspoon)
+[![Build Status](https://img.shields.io/travis/modeset/teaspoon.svg)](https://travis-ci.org/modeset/teaspoon)
+[![Code Climate](https://img.shields.io/codeclimate/github/modeset/teaspoon.svg)](https://codeclimate.com/github/modeset/teaspoon)
+[![Coverage Status](https://img.shields.io/coveralls/modeset/teaspoon/master.svg)](https://coveralls.io/r/modeset/teaspoon?branch=master)
 
+<img src="https://raw.github.com/modeset/teaspoon/master/screenshots/logo_big.png" alt="Logo by Morgan Keys" align="right" />
 <sup>Logo by [Morgan Keys](http://www.morganrkeys.com/)</sup>
 
-Teaspoon is a Javascript test runner built on top of Rails. It can run tests in the browser, or headlessly using PhantomJS or with Selenium WebDriver.
+Teaspoon is a Javascript test runner built for Rails. It runs tests in the browser or headless using PhantomJS or Selenium WebDriver.
 
-Its objective is to be the simplest, while also being the most complete Javascript testing solution for Rails. It takes full advantage of the asset pipeline and ships with support for Jasmine, Mocha, QUnit, and (experimentally) Angular.
+The goal is to be simple, while still providing the most complete Javascript testing solution for Rails.
 
-Ok, another Javascript test runner, right? Really? Yeah, that's tough, but we're pretty confident Teaspoon is one of the nicest and most full featured you'll find at the moment. And if you disagree, let us know and we'll probably fix whatever it is that you didn't like.
+Teaspoon takes advantage of the asset pipeline. And ships with support for Jasmine, Mocha, and QUnit.
 
-Feedback, ideas and pull requests are always welcome, or you can hit us up on Twitter [@modeset_](https://twitter.com/modeset_).
+Ok, another Javascript test runner, right? Yeah, that's tough, but we're pretty confident Teaspoon is one of the nicest and most full featured you'll find at the moment. And if you disagree, let us know and we'll likely fix whatever it is that you didn't like.
+
+Feedback, ideas and pull requests are always welcome, or you can hit us up on Twitter @modeset_.
 
 If you'd like to use Teaspoon with [Guard](https://github.com/guard/guard), check out the [guard-teaspoon](https://github.com/modeset/guard-teaspoon) project.
 
-### Developer Notice:
+Or, if you'd want to use [Spring](https://github.com/rails/spring) preloader, use with  [spring-commands-teaspoon](https://github.com/alejandrobabio/spring-commands-teaspoon).
+
+## Developer Notice
+
+The master branch deviates heavily from 0.7.9 and represents the changes that will be in 0.8. There's a good [wiki article](https://github.com/modeset/teaspoon/wiki/Changelog) about the notable changes and how you can ease the pain of upgrading.
+
+While we know that considerable changes like these can be a pain, they're not made frivolously, and they set the groundwork for what we can all build on and contribute to. There was some cleanup that needed to happen, and some polish, and in that process we tried to think about what we've learned thus far, and how we can better that for future versions. We appreciate your tolerance and willingness to help us fix anything that we missed.
+
+:heart:
+
+### 0.8.0 - follow ups / todo
+
+Here's a short list of things that 0.8.0 might also address.
+
+- add jasmine2 support
+- tests for the require js stuff (this is brittle and since we don't use requirejs, intrinsically hard)
+- hooks could be improved to specify method (get/post), and to pass params -- passing to the blocks if they have arity
 
-Teabag has been renamed to Teaspoon. A deprecation notice was provided with the last release of the gem under the teabag name, and versions will continue to move forward from 0.7.3.
+#### nice to haves
 
-Updating requires that you rename your `teabag.rb` initializer to `teaspoon.rb`, and `teabag_env.rb` to `teaspoon_env.rb`. Replacing any references to teabag to teaspoon within them. Or if you've not made any changes just clean these files up and run the install generator again.
+- a more useful rake task library (like rspec https://www.relishapp.com/rspec/rspec-core/docs/command-line/rake-task)
+- rspec interface, so rspec reporters can be used
 
 
 ## Screenshots
@@ -41,8 +64,8 @@ Updating requires that you rename your `teabag.rb` initializer to `teaspoon.rb`,
 2. [Usage](#usage)
 3. [Writing Specs](#writing-specs)
 4. [Fixtures](#fixtures)
-5. [Coverage](#coverage)
-6. [Suites](#suites)
+5. [Suites](#suites)
+6. [Coverage](#coverage)
 7. [Configuration](#configuration)
 8. [Test Frameworks](#test-frameworks)
 9. [Support Libraries](#support-libraries)
@@ -51,92 +74,102 @@ Updating requires that you rename your `teabag.rb` initializer to `teaspoon.rb`,
 
 ## Installation
 
-Add it to your Gemfile. In most cases you'll want to restrict it to the `:development, :test` or `:asset` groups.
-
-You should [install phantomjs](http://phantomjs.org/download.html).  If phantomjs is found it will be used, otherwise you can use the gem as a fallback -- which might not be optimal.
+Add it to your Gemfile. In most cases you'll want to restrict it to the `:development, :test` groups.
 
 ```ruby
 group :development, :test do
-  gem "phantomjs", ">= 1.8.1.1" # this is optional if you install phantomjs manually (as of teaspoon 0.7.9)
   gem "teaspoon"
 end
 ```
 
-Optionally run the install generator to get the initializer and a basic spec helper.
+Run the install generator to get the environment file and a basic spec helper. You can tell the generator which framework you want to use, if you want a coffeescript spec helper, etc. Run the install generator with the `--help` flag for a list of available options.
 
 ```
-rails generate teaspoon:install
+rails generate teaspoon:install --framework=mocha --coffee
 ```
 
-You can tell the generator which framework you want to use, if you want coffeescript spec helper files, and if you want the env file created (used by the command line interface).
+To run Teaspoon headless you'll need Selenium Webdriver or PhantomJS. We recommend PhantomJS, which you can install with homebrew, npm or [as a download](http://phantomjs.org/download.html).
 
 ```
-rails generate teaspoon:install --framework=mocha --coffee
+brew install phantomjs
+- OR -
+npm install -g phantomjs
 ```
 
+The PhantomJS binary will be used by default if it's available in your path, otherwise you can use the gem as a fallback.
+
+```ruby
+group :development, :test do
+  gem "teaspoon"
+  gem "phantomjs", ">= 1.8.1.1" # this is optional if the phantomjs binary is installed (as of teaspoon 0.7.9)
+end
+```
+
+### Upgrading
+
+We made some changes to how configuration and loading works for version 0.8.0, which might cause some confusion. For this we're sorry, but it'll be better in the long run -- and hey, on the up side, we didn't write a javascript test runner and then abandon it.
+
+1. backup your `spec/teaspoon_env.rb` file.
+2. run the install generator to get the new `teaspoon_env.rb`.
+3. migrate your old settings into the new file, noting the changes that might exist.
+4. move all settings that you had in `config/initializers/teaspoon.rb` into `spec/teaspoon_env.rb` and delete the initializer.
+
+
 ## Usage
 
-Teaspoon uses the Rails asset pipeline to serve files. This allows you to use `= require` in your test files, and allows you use things like HAML or RABL/JBuilder within your fixtures.  You can run Teaspoon in three ways -- in the browser, via the rake task, and using the command line interface.
+Teaspoon uses the Rails asset pipeline to serve files. This allows you to use `= require` in your test files, and allows you use things like HAML or RABL/JBuilder within your fixtures.
 
 Here's a great [Quick Start Walkthrough](https://github.com/modeset/teaspoon/wiki/Quick-Start-Walkthrough) for writing and running your first tests.
 
+You can run Teaspoon three ways -- in the browser, via the rake task, and using the command line interface (CLI).
+
 ### Browser
 
 ```
 http://localhost:3000/teaspoon
 ```
 
-You can focus tests in various ways, and Teaspoon provides an interface to run focus tests by suite, file, and filter.
-
 ### Rake
 
-The rake task provides several ways of foucusing tests. You can specify the suite to run, the files to run, and/or directories to run.
+```
+rake teaspoon
+```
+
+The rake task provides several ways of focusing tests. You can specify the suite to run, the files to run, directories to run, etc.
 
 ```
 rake teaspoon suite=my_fantastic_suite
-rake teaspoon files=test/javascripts/controllers/my_controller_test.js
-rake teaspoon files=test/javascripts/integration,test/javascripts/models
-rake teaspoon files=test/javascripts/integration,test/javascripts/models,test/javascripts/controllers/my_controller_test.js
-rake teaspoon suite=my_fantastic_suite files=test/javascripts/integration,test/javascripts/models,test/javascripts/controllers/my_controller_test.js
+rake teaspoon files=spec/javascripts/integration,spec/javascripts/calculator_spec.js
 ```
 
-### Command Line Interface
-
-The command line interface requires a `teaspoon_env.rb` file that you can get by running the generator. This file is used to load the Rails environment so Teaspoon can run within the context of Rails. This file can be in the spec, test, or root path -- but can be specified using the `--require` option.
+### CLI
 
 ```
 bundle exec teaspoon
 ```
 
-The CLI provides several ways of focusing tests. You can specify the suite to run, the files to run, directories to run, and a filter.
+The CLI also provides several ways of focusing tests. You can specify the suite to run, the files to run, directories to run, filters, etc.
 
 ```
 bundle exec teaspoon --suite=my_fantastic_suite
-bundle exec teaspoon spec/javascripts/calculator_spec.js
-bundle exec teaspoon spec/javascripts/integration
+bundle exec teaspoon spec/javascripts/integration spec/javascripts/calculator_spec.js
 bundle exec teaspoon --filter="Calculator should add two digits"
 ```
 
-Teaspoon also has support for [tapout](https://github.com/rubyworks/tapout). Use the tap_y formatter and pipe the results to tapout to use any of the reporters that tapout provides.
-
-```
-bundle exec teaspoon -q --format=tap_y | tapout progress
-```
-
 Get full command line help:
 
 ```
 bundle exec teaspoon --help
 ```
 
-**Note:** By default the rake task and command line interface run within the development environment, but you can specify the environment using `RAILS_ENV=test rake teaspoon`. This is to stay consistent with what you might see in the browser (since that's likely running in development).
+**Note:** The rake task and CLI run within the development environment unless otherwise specified.
 
 
 ## Writing Specs
 
-Depending on what framework you use this can be slightly different. There's an expectation that you have a certain level of familiarity with the test framework that you're using. Right now Teaspoon supports [Jasmine](http://pivotal.github.com/jasmine), [Mocha](http://visionmedia.github.com/mocha) and [QUnit](http://qunitjs.com).
+Depending on which framework you use this can differ, and there's an expectation that you have a certain level of familiarity with your chosen test framework.
 
-Since we have the asset pipeline at our fingertips you can feel free to use the `= require` directive throughout your specs and spec helpers.
+Teaspoon supports [Jasmine](http://pivotal.github.com/jasmine), [Mocha](http://visionmedia.github.com/mocha) and [QUnit](http://qunitjs.com). And since it's possible to use the asset pipeline, feel free to use the `= require` directive throughout your specs and spec helpers.
 
 Here's a basic spec written in Javascript using Jasmine:
 
@@ -152,72 +185,69 @@ describe("My great feature", function() {
 });
 ```
 
-Check out examples of a [Mocha Spec](https://github.com/modeset/teaspoon/wiki/Using-Mocha), a [QUnit Test](https://github.com/modeset/teaspoon/wiki/Using-QUnit), and an [Angular Test](https://github.com/modeset/teaspoon/wiki/Using-Angular).
+You can also check out the examples of a [Mocha Spec](https://github.com/modeset/teaspoon/wiki/Using-Mocha), and a [QUnit Test](https://github.com/modeset/teaspoon/wiki/Using-QUnit).
 
 ### Pending Specs
 
-We've normalized declaring that a spec is pending between Mocha and Jasmine. Since Jasmine lacks the concept we've added it in, and since Mocha has several ways to accomplish it we thought it would be worth mentioning what we consider the standard between the two to be. QUnit doesn't support specifying a test as pending.
+Every test framework is different, but we've tried to normalize some of those differences. For instance, Jasmine lacks the concept pending, while Mocha provides several ways to achieve this. So we thought it would be worth defining what is standard between the two frameworks. QUnit doesn't easily support the concept of pending, so that's not covered.
 
-To mark a spec as pending you can either not provide a function as the second argument to `it`, or you can use `xit` and `xdescribe`. Mocha provides some additional ways to accomplish this, but to keep it consistent we've normalized on what they both support.
+To mark a spec as pending in both Mocha and Jasmine, you can either not provide a function as the second argument to the `it` call, or you can use `xit` and `xdescribe`.
 
-```coffeescript
-describe "My great feature", ->
+```javascript
+describe("My great feature", function() {
+  it("hasn't been tested yet");
 
-  it "hasn't been tested yet"
+  xit("has a test I can't figure out", function() {
+    expect("complexity").to.be("easily testable");
+  });
 
-  xit "has a test I can't figure out" ->
-    expect("complexity").to.be("easily testable")
+  xdescribe("A whole section that I've not gotten to", function() {
+    it("hasn't been tested yet", function() {
+      expect(true).to.be(false);
+    });
+  });
+});
+```
 
-  xdescribe "A whole section that I've not gotten to", ->
+### Deferring Execution
 
-    it "hasn't been tested yet", ->
-      expect(true).to.be(false)
-```
+Teaspoon allows deferring execution, which can be useful for asynchronous execution.
 
-If you're using a specific framework and you want to take advantage of the things that framework provides you're free to do so. This is provided as the standard as the Teaspoon reporters understand the techniques above and have specs for them.
+```javascript
+Teaspoon.defer = true;
+setTimeout(Teaspoon.execute, 1000); // defers execution for 1 second as an example
+```
 
 ### Using Require.js
-If you are using require.js to get your files you can set a configuration option for your suite of "use_require".
-```ruby
-Teaspoon.setup do |config|
-  config.suite do |suite|
-    suite.use_require = true
-  end
-end
-```
-Then in your suite spec helper, add require.js to be included, if you have not already. (Note: Teaspoon doesn't include require.js with it, so you will need to provide your own require.js and require the correct path.)
+
+You can configure your suite to boot with require.js by setting the suite `boot_partial` directive to `"boot_require_js"`.
+
+Be sure to require `require.js` in your spec helper. Teaspoon doesn't include it as a support library, so you'll need to provide your own.
+
 ```javascript
 //= require require
 ```
 
-Once you've done that, when that suite is executed, Teaspoon will use require.js to get all the specs in the suite (or specific files). In your specs you will need to use require to pull down the dependencies as you would normally. Here is an example with mocha.
+Now require.js will be used to load all the specs in your suite, however, you'll still need to use require.js to pull down the dependencies as you would normally.
+
 ```javascript
-define(['Model'] , function (Model) {
-  describe('Model' , function () {
-    // put your tests here
+define(['Model'], function (Model) {
+  describe('Model', function () {
+    // ...
   });
 });
 ```
 
-### Deferring Execution
-
-Teaspoon allows deferring execution in the cases when you're using AMD or other asynchronous libraries. This is especially useful if you're using [CommonJS](http://www.commonjs.org/), etc.  You can tell Teaspoon to defer and then execute the runner yourself later -- after loading asychronously. There's a wiki article about how you can setup your specs and spec helper when using [RequireJS with Teaspoon](https://github.com/modeset/teaspoon/wiki/RequireJS-with-Teaspoon).
-
-```javascript
-Teaspoon.defer = true;
-setTimeout(Teaspoon.execute, 1000); // defers execution for 1 second
-```
-
 
 ## Fixtures
 
-You're free to use your own fixture library (like jasmine-jquery, which we've included as a support library), but Teaspoon ships with a fixture library that works with Jasmine, Mocha, and QUnit with a minimum of effort, has a nice consistent API, and isn't dependent on jQuery.
+Teaspoon ships with a fixture library that works with Jasmine, Mocha, and QUnit with a minimum of effort, has a nice consistent API, and isn't dependent on jQuery.
 
-The fixture path is configurable within Teaspoon, and the views will be rendered by a standard controller.  This allows you to use things like RABL/JBuilder if you're building JSON, or HAML if you're building markup.  The element that Teaspoon creates is "#teaspoon-fixtures", in case you need to access it directly -- or you can access it via `fixture.el` after loading fixtures.
+The fixture path is configurable within Teaspoon, and the views will be rendered by a standard controller. This allows you to use things like RABL/JBuilder if you're building JSON, or HAML if you're building markup.
 
 ### Loading Files
 
-Loading fixtures allows you to specify any number of files to load, and if they should be appended to the fixture element, or replace what's currently there.
+Loading fixtures allows you to specify any number of files to load, and if they should be appended to the fixture element or replace what's currently there.
 
 `fixture.load(url[, url, ...], append = false)` or `fixture(url[, url, ...], append = false)`
 
@@ -235,44 +265,105 @@ You shouldn't have to cleanup (we do that for you based on your test framework),
 
 ### Preloading Files
 
-Some test cases require stubbing Ajax requests, and in those cases you may want to preload the fixture files -- which caches them for later.  You can preload fixtures in your spec helper, or before you start mocking Ajax methods.
+Some test cases require stubbing Ajax requests, and in those cases you may want to preload the fixture files to cache them for later.  You can preload fixtures in your spec helper, or before you start mocking Ajax methods.
 
 `fixture.preload(url[, url, ...])`
 
 ### Example Usage
 
-```coffeescript
-fixture.preload("fixture.html", "fixture.json") # make the actual requests for the files
-describe "Using fixtures", ->
-
-  fixture.set("<h2>Another Title</h2>") # create some markup manually (will be in a beforeEach)
+```javascript
+fixture.preload("fixture.html", "fixture.json"); // make the actual requests for the files
+describe("Using fixtures", function() {
+  fixture.set("<h2>Another Title</h2>"); // create some markup manually (will be in a beforeEach)
 
-  beforeEach ->
-    @fixtures = fixture.load("fixture.html", "fixture.json", true) # append these fixtures which were already cached
+  beforeEach(function() {
+    this.fixtures = fixture.load("fixture.html", "fixture.json", true); // append these fixtures which were already cached
+  });
 
-  it "loads fixtures", ->
-    expect($("h1", fixture.el).text()).toBe("Title") # using fixture.el as a jquery scope
+  it("loads fixtures", function() {
+    expect($("h1", fixture.el).text()).toBe("Title") // using fixture.el as a jquery scope
     expect($("h2", fixture.el).text()).toBe("Another Title")
-    expect(@fixtures[0]).toBe(fixture.el) # the element is available as a return value and through fixture.el
-    expect(@fixtures[1]).toEqual(fixture.json[0]) # the json for json fixtures is returned, and available in fixture.json
+    expect(this.fixtures[0]).toBe(fixture.el) // the element is available as a return value and through fixture.el
+    expect(this.fixtures[1]).toEqual(fixture.json[0]) // the json for json fixtures is returned, and available in fixture.json
+  });
+});
 ```
 
-Check out some example of using fixtures with [Mocha](https://github.com/modeset/teaspoon/wiki/Using-Mocha), [QUnit](https://github.com/modeset/teaspoon/wiki/Using-QUnit), and [Angular](https://github.com/modeset/teaspoon/wiki/Using-Angular).
+Check out some example of using fixtures with [Mocha](https://github.com/modeset/teaspoon/wiki/Using-Mocha), [QUnit](https://github.com/modeset/teaspoon/wiki/Using-QUnit).
+
+**Note:** The element that Teaspoon creates is "#teaspoon-fixtures", in case you need to access it directly.
+
+
+## Suites
+
+Teaspoon uses the concept of suites to group tests at a high level. These suites run in isolation and can have different configurations.
+
+A default suite has been generated for you in your `teaspoon_env.rb`.
+
+Suites inherit from a "default" suite. To modify the "default" suite simply don't specify a name for the suite. In this example we're configuring the default suite, which all other suites will inherit from.
+
+```ruby
+config.suite do |suite|
+  suite.helper = "other_spec_helper.js"
+end
+```
+
+When defining a custom suite, provide a name and a block. The following example defines a suite named "my_suite".
+
+```ruby
+config.suite :my_suite do |suite|
+  suite.helper = "my_spec_helper.js"
+end
+```
+
+### Hooks
+
+Hooks are designed to facilitate loading fixtures or other things that might be required on the back end before, after, or during running a suite or test. You can define hooks in your suite by specifying a name and a block. Hooks with the same name will be added to an array, and all will be called when the hook is requested. If you don't specify a name, :default will be assumed.
+
+```ruby
+config.suite :my_suite do |suite|
+  suite.hook :fixtures do
+    # some code that would load your fixtures
+  end
+end
+```
+
+You can then use the javascript `Teaspoon.hook("fixtures")` call at the beginning of a suite run or similar. All blocks that have been specified for a given hook will be called in the order they were defined.
+
+### Manifest Style
+
+Teaspoon is happy to look for files for you (and this is recommended), but you can disable this feature and maintain a manifest yourself. Configure the suite to not match any files, and then use your spec helper to create your manifest.
+
+```ruby
+config.suite do |suite|
+  suite.matcher = nil
+  suite.helper = "spec_manifest"
+end
+```
+
+**Note:** This limits your ability to run specific files from the command line interface and other benefits, and so isn't recommended.
 
 
 ## Coverage
 
-Teaspoon can use [Istanbul](https://github.com/gotwarlost/istanbul) to generate code coverage statistics and reports. Install Istanbul and adjust the configuration to always generate coverage reports, or specify by passing `--coverage` to the command line interface. Check the [configuration](#configuration) for more information.
+Teaspoon uses [Istanbul](https://github.com/gotwarlost/istanbul) to generate code coverage statistics and reports. You can define coverage configurations the same way you define suites.
+
+Each suite allows specifying ignored files, which allows you to ignore support libraries and dependencies.
 
-Each suite allows you to specify which files should be ignored when generating coverage reports, which allows you to ignore support libraries and dependencies that you're not testing.
+The following configuration and example generates a text and cobertura report -- and an annotated HTML report that you can inspect further.
 
-The following example will generate a simple text report and an HTML report with annotated source that you can inspect further.
+```ruby
+config.coverage do |coverage|
+  coverage.reports = ['text', 'html', 'cobertura']
+end
+```
 
 ```shell
-bundle exec teaspoon --coverage-reports=text,html
+bundle exec teaspoon --coverage=default
 ```
 
-An example text report that's output to the console after the tests have completed.
+If you use the `"text"`, or `"text-summary"` reports, they will be output to the console after the tests have completed.
+
 ```
 --------------------+-----------+-----------+-----------+-----------+
 File                |   % Stmts |% Branches |   % Funcs |   % Lines |
@@ -284,99 +375,109 @@ All files           |     93.75 |        75 |     94.12 |     93.65 |
 --------------------+-----------+-----------+-----------+-----------+
 ```
 
-Teaspoon can have thresholds to fail the build (i.e. return an exit code not equal to zero). These are the same as istanbul: statement, function, branch and line coverage thresholds. They can be set in your environment file:
+### Thresholds
+
+Teaspoon allows defining coverage threshold requirements. If a threshold is not met, it will cause a test run failure.
+
+This example would cause a failure if less than 50% of the statements were not covered by the tests for instance.
 
 ```ruby
-Teaspoon.setup do |config|
-  config.statements_coverage_threshold = 50
-  config.functions_coverage_threshold  = 50
-  config.branches_coverage_threshold   = 50
-  config.lines_coverage_threshold      = 50
+config.coverage :CI do |coverage|
+  coverage.statements = 50
+  coverage.functions  = 50
+  coverage.branches   = 50
+  coverage.lines      = 50
 end
 ```
 
-or on the command line:
-
-```shell
-bundle exec teaspoon --coverage true --statements-coverage-threshold 50 --functions-coverage-threshold 50 --branches-coverage-threshold 50 --lines-coverage-threshold 50
-```
 
+## Configuration
 
-## Suites
+When you install Teaspoon a `teaspoon_env.rb` file is generated that contains most of this information, but we've provided it here too.
 
-Teaspoon uses the concept of suites to group your tests at a high level. These suites are run in isolation from one another, and can have different configurations. You can define suites in the configuration, and for brevity `config` is the argument passed to the `Teaspoon.setup` block.
+<dl>
 
-When creating a suite, provide a name (optional) and a block. The following example defines a suite named "my_suite". You can focus run this suite by browsing to `/teaspoon/my_suite` or running the rake task with `suite=my_suite`.
+<dt> mount_at </dt><dd>
+  Determines where the Teaspoon routes will be mounted. Changing this to "/jasmine" would allow you to browse to <code>http://localhost:3000/jasmine</code> to run your tests.<br/><br/>
 
-```ruby
-config.suite :my_suite do |suite|
-  suite.helper = "my_spec_helper.js"
-end
-```
+  <b>default:</b> <code>"/teaspoon"</code>
+</dd>
 
-There's always a "default" suite defined, and to modify this suite just don't specify a name, or use `:default`. In this example we're setting the default suite configuration.
+<dt> root </dt><dd>
+  Specifies the root where Teaspoon will look for files. If you're testing an engine using a dummy application it can be useful to set this to your engines root (e.g. <code>Teaspoon::Engine.root</code>).<br/>
+  <b>Note:</b> Defaults to <code>Rails.root</code> if nil.<br/><br/>
 
-```ruby
-config.suite do |suite|
-  suite.helper = "other_spec_helper.js"
-end
-```
+  <b>default:</b> <code>nil</code>
+</dd>
 
-**Note:** Suites inherit from the default suite, so default configuration will propagate to all other suites.
+<dt> asset_paths </dt><dd>
+  Paths that will be appended to the Rails assets paths.<br/>
+  <b>Note:</b> Relative to <code>config.root</code>.<br/><br/>
 
-### Manifest Style
+  <b>default:</b> <code>["spec/javascripts", "spec/javascripts/stylesheets", "test/javascripts", "test/javascripts/stylesheets"]</code>
+</dd>
 
-Teaspoon is happy to look for files for you, but you can disable this feature and maintain a manifest yourself.  Each suite can utilize a different spec helper and you can use these to create your own manifest using the `= require` directive. This isn't recommended because it limits your abilities to run specific files from the command line interface, but it's available if you want to use it.
+<dt> fixture_paths </dt><dd>
+  Fixtures are rendered through a controller, which allows using HAML, RABL/JBuilder, etc. Files in this path will be rendered as fixtures.<br/><br/>
 
-Tell the suite that you don't want it to match any files, and then require files in your spec helper.
+  <b>default:</b> <code>["spec/javascripts/fixtures", "test/javascripts/fixtures"]</code>
+</dd>
 
-```ruby
-config.suite do |suite|
-  suite.matcher = nil
-  suite.helper = "spec_manifest"
-end
-```
+</dl>
 
 ### Suite Configuration Directives
 
 <dl>
 
-<dt> matcher </dt><dd>
-  You can specify a file matcher and all matching files will be loaded when the suite is run. It's important that these files can be served via sprockets / are within an asset path.<br/><br/>
+<dt> use_framework(name[, version]) </dt><dd>
+  Specify the framework and optionally version you would like to use. This will do some basic setup for you -- which you can override with the directives below. This should be specified first, as it can override other directives.<br/><br/>
+  <b>Note:</b> If no version is specified, the latest is assumed.<br/><br/>
 
-  <b>Note:</b> Can also be set to <code>nil</code>.<br/><br/>
+  <b>available:</b> jasmine[1.3.1, 2.0.0], mocha[1.10.0, 1.17.1] qunit[1.12.0, 1.14.0]<br/>
+  <b>default:</b> <code>[no default]</code>
+</dd>
+
+<dt> matcher </dt><dd>
+  Specify a file matcher as a regular expression and all matching files will be loaded when the suite is run. These files need to be within an asset path. You can add asset paths using the `config.asset_paths`.<br/>
+  <b>Note:</b> Can be set to <code>nil</code> to match no files.<br/><br/>
 
   <b>default:</b> <code>"{spec/javascripts,app/assets}/**/*_spec.{js,js.coffee,coffee}"</code>
 </dd>
 
 <dt> helper </dt><dd>
-  Each suite can load a different spec helper, which can in turn require additional files. This file is loaded before your specs are loaded, and can be used as a manifest.<br/><br/>
+  This suites spec helper, which can require additional support files. This file is loaded before any of your test files are loaded.<br/><br/>
 
   <b>default:</b> <code>"spec_helper"</code>
 </dd>
 
 <dt> javascripts </dt><dd>
-  These are the core Teaspoon javascripts. It's strongly encouraged to include only the base files here. You can require other support libraries in your spec helper, which allows you to change them without having to restart the server.<br/><br/>
-
-  <b>Note:</b> To use the CoffeeScript source files use <code>"teaspoon/jasmine"</code> etc.<br/><br/>
+  The core Teaspoon javascripts. If you're using the `use_framework` directive this will be set based on that, but it can be useful to provide an override to use a custom version of a test framework.<br/>
+  <b>Note:</b> It's recommended to only include the core files here, as you can require support libraries from your spec helper.<br/>
+  <b>Note:</b> For CoffeeScript files use <code>"teaspoon/jasmine"</code> etc.<br/><br/>
 
   <b>available:</b> teaspoon-jasmine, teaspoon-mocha, teaspoon-qunit<br/>
-  <b>default:</b> <code>["teaspoon-jasmine"]</code>
+  <b>default:</b> <code>["jasmine/1.3.1", "teaspoon-jasmine"]</code>
 </dd>
 
 <dt> stylesheets </dt><dd>
-  If you want to change how Teaspoon looks, or include your own stylesheets you can do that here. The default is the stylesheet for the HTML reporter.<br/><br/>
-
-  <b>Note:</b> Spec related CSS can and should be loaded using fixtures.
+  You can include your own stylesheets if you want to change how Teaspoon looks.<br/>
+  <b>Note:</b> Spec related CSS can and should be loaded using fixtures.<br/><br/>
 
   <b>default:</b> <code>["teaspoon"]</code>
 </dd>
 
-<dt> no_coverage </dt><dd>
-  When running coverage reports, you probably want to exclude libraries that you're not testing.
-  Accepts an array of filenames or regular expressions. The default is to exclude assets from vendors or gems.<br/><br/>
+<dt> boot_partial </dt><dd>
+  Partial to be rendered in the head tag of the runner. You can use the provided ones or define your own by creating a `_boot.html.erb` in your fixtures path, and adjust the config to `"/boot"` for instance.<br/><br/>
 
-  <b>default:</b> <code>`[%r{/lib/ruby/gems/}, %r{/vendor/assets/}, %r{/support/}, %r{/(.+)_helper.}]`</code>
+  <b>available:</b> boot, boot_require_js<br/>
+  <b>default:</b> <code>"boot"</code>
+</dd>
+
+<dt> normalize_asset_path </dt><dd>
+  When using custom file-extensions you might need to supply a custom asset path normalization. If you need to match a
+  custom extension, simply supply a custom lambda/proc that returns the desired filename.<br/><br/>
+
+  <b>default:</b> <code>`filename.gsub('.erb', '').gsub(/(\.js\.coffee|\.coffee)$/, ".js")`</code>
 </dd>
 
 </dl>
@@ -386,180 +487,212 @@ end
 
 The best way to read about the configuration options is to generate the initializer and env, but we've included the info here as well.
 
-**Note:** `Teaspoon.setup` may not be available in all environments, so the generator wraps it within a check.
-
-<dl>
-
-<dt> mount_at </dt><dd>
-  This determines where the Teaspoon routes will be mounted. Changing this to "/jasmine" would allow you to browse to http://localhost:3000/jasmine to run your specs.<br/><br/>
+<dt> body_partial </dt><dd>
+  Partial to be rendered in the body tag of the runner. You can define your own to create a custom body structure.<br/><br/>
 
-  <b>default:</b> <code>"/teaspoon"</code>
+  <b>default:</b> <code>"body"</code>
 </dd>
 
-<dt> root </dt><dd>
-  This defaults to Rails.root if left nil. If you're testing an engine using a dummy application it can be useful to set this to your engines root.. E.g. <code>Teaspoon::Engine.root</code><br/><br/>
-
-  <b>default:</b> <code>nil</code>
-</dd>
-
-<dt> asset_paths </dt><dd>
-  These paths are appended to the Rails assets paths (relative to config.root), and by default is an array that you can replace or add to.<br/><br/>
+<dt> no_coverage </dt><dd>
+  Assets to be ignored when generating coverage reports. Accepts an array of filenames or regular expressions. The default excludes assets from vendor, gems and support libraries.<br/><br/>
 
-  <b>default:</b> <code>["spec/javascripts", "spec/javascripts/stylesheets", "test/javascripts", "test/javascripts/stylesheets"]</code>
+  <b>default:</b> <code>[%r{/lib/ruby/gems/}, %r{/vendor/assets/}, %r{/support/}, %r{/(.+)_helper.}]</code>
 </dd>
 
-<dt> fixture_path </dt><dd>
-  Fixtures are rendered through a standard controller. This means you can use things like HAML or RABL/JBuilder, etc. to generate fixtures within this path.<br/><br/>
+<dt> hook(name, &block) </dt><dd>
+  Hooks allow you to use `Teaspoon.hook("fixtures")` before, after, or during your spec run. This will make a synchronous Ajax request to the server that will call all of the blocks you've defined for that hook name. (e.g. <code>suite.hook :fixtures, proc{ }</code>)
 
-  <b>default:</b> <code>"spec/javascripts/fixtures"</code>
+  <b>default:</b> <code>Hash.new{ |h, k| h[k] = [] }</code>
 </dd>
 
 </dl>
 
-### Console Runner Specific (Teaspoon Env)
+### Console Runner Specific
 
-These configuration directives are applicable only when running via the rake task or command line interface and should be set within the teaspoon_env.rb file. You can get this file by running the generator.
+These configuration directives are applicable only when running via the rake task or command line interface. These directives can be overridden using the command line interface arguments or with ENV variables when using the rake task.
 
 <dl>
 
 <dt> driver </dt><dd>
-  Allows you to specify which driver to use when running headlessly. Supports <a href="http://phantomjs.org">PhantomJS</a> and <a href="http://seleniumhq.org/docs/03_webdriver.jsp">Selenium Webdriver</a>.<br/><br/>
+  Specify which headless driver to use. Supports <a href="http://phantomjs.org">PhantomJS</a> and <a href="http://seleniumhq.org/docs/03_webdriver.jsp">Selenium Webdriver</a>.<br/><br/>
 
-  Check this wiki article for information about <a href="https://github.com/modeset/teaspoon/wiki/Using-Selenium-WebDriver">Using Selenium WebDriver</a>, and this one about <a href="https://github.com/modeset/teaspoon/wiki/Using-PhantomJS">Using PhantomJS</a>.<br/><br/>
+  <a href="https://github.com/modeset/teaspoon/wiki/Using-PhantomJS">Using PhantomJS</a>.<br/>
+  <a href="https://github.com/modeset/teaspoon/wiki/Using-Selenium-WebDriver">Using Selenium WebDriver</a><br/><br/>
 
   <b>available:</b> phantomjs, selenium<br/>
   <b>default:</b> <code>"phantomjs"</code>
 
   <ul>
     <li>CLI: -d, --driver DRIVER</li>
-    <li>ENV: DRIVER=selenium</li>
+    <li>ENV: DRIVER=[DRIVER]</li>
   </ul>
 </dd>
 
-<dt> driver_cli_options </dt><dd>
-  An experimental feature to allow you to specify additional CLI options/switches. Currently this is only supported if using the 'phantomjs' driver.<br/><br/>
+<dt> driver_options </dt><dd>
+  Specify additional options/switches for the driver.<br/><br/>
 
-  Check this wiki article for information about <a href="https://github.com/ariya/phantomjs/wiki/API-Reference#command-line-options">PhantomJS Command-line Options</a>. Some options may cause Teaspoon to fail to function as expected/may not produce the expected result or may conflict with other options.<br/><br/>
+  <a href="https://github.com/modeset/teaspoon/wiki/Using-PhantomJS">Using PhantomJS</a>.<br/>
+  <a href="https://github.com/modeset/teaspoon/wiki/Using-Selenium-WebDriver">Using Selenium WebDriver</a><br/><br/>
 
   <b>default:</b> <code>nil</code>
 
   <ul>
-    <li>CLI: -o, --driver-cli-options OPTIONS_STRING</li>
-    <li>ENV: DRIVER_CLI_OPTIONS="--ssl-protocol=any --ssl-certificates-path=/path/to/certs"</li>
+    <li>CLI: --driver-options OPTIONS</li>
+    <li>ENV: DRIVER_OPTIONS=[OPTIONS]</li>
   </ul>
 </dd>
 
-<dt> server </dt><dd>
-  Specify a server to use with Rack (eg. thin, mongrel). If nil is provided Rack::Server is used.<br/><br/>
+<dt> driver_timeout </dt><dd>
+  Specify the timeout for the driver. Specs are expected to complete within this time frame or the run will be considered a failure. This is to avoid issues that can arise where tests stall.<br/><br/>
 
-  <b>default:</b> <code>nil</code>
+  <b>default:</b> <code>180</code>
 
   <ul>
-    <li>CLI: --server SERVER</li>
-    <li>ENV: SERVER=thin</li>
+    <li>CLI: --driver-timeout SECONDS</li>
+    <li>ENV: DRIVER_TIMEOUT=[SECONDS]</li>
   </ul>
 </dd>
 
-<dt> server_timeout </dt><dd>
-  Timeout for starting the server in seconds. If your server is slow to start you may have to bump this, or you may want to lower this if you know it shouldn't take long to start.<br/><br/>
+<dt> server </dt><dd>
+  Specify a server to use with Rack (e.g. thin, mongrel). If nil is provided Rack::Server is used.<br/><br/>
 
-  <b>default:</b> <code>20</code>
+  <b>default:</b> <code>nil</code>
 
   <ul>
-    <li>CLI: --server-timeout SECONDS</li>
-    <li>ENV: SERVER_TIMEOUT=10</li>
+    <li>CLI: --server SERVER</li>
+    <li>ENV: SERVER=[SERVER]</li>
   </ul>
 </dd>
 
 <dt> server_port </dt><dd>
-  By default Teaspoon will locate an open port when starting the server, but if you want to run on a specific port you can do so by providing one.<br/><br/>
+  Specify a port to run on a specific port, otherwise Teaspoon will use a random available port.<br/><br/>
 
   <b>default:</b> <code>nil</code>
 
   <ul>
     <li>CLI: --server-port PORT</li>
-    <li>ENV: SERVER_PORT=31337</li>
+    <li>ENV: SERVER_PORT=[PORT]</li>
   </ul>
 </dd>
 
+<dt> server_timeout </dt><dd>
+  Timeout for starting the server in seconds. If your server is slow to start you may have to bump this, or you may want to lower this if you know it shouldn't take long to start.<br/><br/>
 
-<dt> fail_fast </dt><dd>
-  If you have several suites it can be useful to make Teaspoon fail directly after any suite contains failures, but in environments like CI this may not be desirable.<br/><br/>
-
-  <b>default:</b> <code>true</code>
+  <b>default:</b> <code>20</code>
 
   <ul>
-    <li>CLI: --[no-]fail-fast</li>
-    <li>ENV: FAIL_FAST=false</li>
+    <li>CLI: --server-timeout SECONDS</li>
+    <li>ENV: SERVER_TIMEOUT=[SECONDS]</li>
   </ul>
 </dd>
 
-<dt> formatters </dt><dd>
-  You can specify the formatters that Teaspoon will use when outputting the results.<br/><br/>
+<dt> fail_fast </dt><dd>
+  Force Teaspoon to fail immediately after a failing suite. Can be useful to make Teaspoon fail early if you have several suites, but in environments like CI this may not be desirable.<br/><br/>
 
-  <b>available:</b> dot, tap, tap_y, swayze_or_oprah<br/>
-  <b>default:</b> <code>"dot"</code>
+  <b>default:</b> <code>true</code>
 
   <ul>
-    <li>CLI: -f, --format FORMATTERS</li>
-    <li>ENV: FORMATTERS=dot,swayze_or_oprah</li>
+    <li>CLI: -F, --[no-]fail-fast</li>
+    <li>ENV: FAIL_FAST=[true/false]</li>
   </ul>
 </dd>
 
-<dt> suppress_log </dt><dd>
-  Teaspoon pipes all console[log/debug/error] calls to STDOUT. This is useful to catch places where you've forgotten to remove them, but in verbose applications this may not be desirable.<br/><br/>
+<dt> formatters </dt><dd>
+  Specify the formatters to use when outputting the results.<br/>
+  <b>Note:</b> Output files can be specified by using <code>"junit>/path/to/output.xml"</code>.<br/><br/>
 
-  <b>default:</b> <code>false</code>
+  <b>available:</b> dot, documentation, clean, json, junit, pride, snowday, swayze_or_oprah, tap, tap_y, teamcity<br/>
+  <b>default:</b> <code>"dot"</code>
 
   <ul>
-    <li>CLI: -q, --[no-]suppress-log</li>
-    <li>ENV: SUPPRESS_LOG=true</li>
+    <li>CLI: -f, --format FORMATTERS</li>
+    <li>ENV: FORMATTERS=[FORMATTERS]</li>
   </ul>
 </dd>
 
 <dt> color </dt><dd>
-  Specify if you want color output by default.<br/><br/>
+  Specify if you want color output from the formatters.<br/><br/>
 
   <b>default:</b> <code>true</code>
 
   <ul>
     <li>CLI: -c, --[no-]color</li>
-    <li>ENV: COLOR=false</li>
+    <li>ENV: COLOR=[true/false]</li>
   </ul>
 </dd>
 
-<dt> coverage </dt><dd>
-  Add instrumentation to your code and display coverage information. Requires <a href="https://github.com/gotwarlost/istanbul">istanbul</a>.<br/><br/>
+<dt> suppress_log </dt><dd>
+  Teaspoon pipes all console[log/debug/error] to $stdout. This is useful to catch places where you've forgotten to remove them, but in verbose applications this may not be desirable.<br/><br/>
 
   <b>default:</b> <code>false</code>
 
   <ul>
-    <li>CLI: -C, --coverage</li>
-    <li>ENV: COVERAGE=true</li>
+    <li>CLI: -q, --[no-]suppress-log</li>
+    <li>ENV: SUPPRESS_LOG=[true/false]</li>
   </ul>
 </dd>
 
-<dt> coverage_reports </dt><dd>
-  Specify which code coverage reports instanbul should generate.<br/><br/>
+<dt> use_coverage </dt><dd>
+  Specify that you always want a coverage configuration to be used.<br/><br/>
 
-  <b>available:</b> text-summary, text, html, lcov, lcovonly, cobertura<br/>
   <b>default:</b> <code>nil</code>
 
   <ul>
-    <li>CLI: -R, --coverage-reports REPORTS</li>
-    <li>ENV: COVERAGE_REPORTS=text,html</li>
+    <li>CLI: -C, --coverage=CONFIG_NAME</li>
+    <li>ENV: USE_COVERAGE=[CONFIG_NAME]</li>
   </ul>
 </dd>
 
-<dt> coverage_output_dir </dt><dd>
-  Specify directory where coverage reports should be generated.<br/><br/>
+</dl>
+
+### Coverage Configuration Directives
+
+<dl>
+
+<dt> reports </dt><dd>
+  Which coverage reports Instanbul should generate. Correlates directly to what Istanbul supports.<br/><br/>
+
+  <b>available:</b> text-summary, text, html, lcov, lcovonly, cobertura, teamcity<br/>
+  <b>default:</b> <code>["text-summary", "html"]</code>
+</dd>
+
+<dl>
+
+<dt> output_dir </dt><dd>
+  The path that the coverage should be written to - when there's an artifact to write to disk.<br/>
+  <b>Note:</b> Relative to <code>config.root</code>.<br/><br/>
 
   <b>default:</b> <code>"coverage"</code>
+</dd>
 
-  <ul>
-    <li>CLI: -O, --coverage-output-dir DIR</li>
-    <li>ENV: COVERAGE_OUTPUT_DIR=coverage</li>
-  </ul>
+<dl>
+
+<dt> statements </dt><dd>
+  Specify a statement threshold. If this coverage threshold isn't met the test run will fail. (0-100) or nil.<br/><br/>
+
+  <b>default:</b> <code>nil</code>
+</dd>
+
+<dl>
+
+<dt> functions </dt><dd>
+  Specify a function threshold. If this coverage threshold isn't met the test run will fail. (0-100) or nil.<br/><br/>
+
+  <b>default:</b> <code>nil</code>
+</dd>
+
+<dl>
+
+<dt> branches </dt><dd>
+  Specify a branch threshold. If this coverage threshold isn't met the test run will fail. (0-100) or nil.<br/><br/>
+
+  <b>default:</b> <code>nil</code>
+</dd>
+
+<dt> lines </dt><dd>
+  Specify a line threshold. If this coverage threshold isn't met the test run will fail. (0-100) or nil.<br/><br/>
+
+  <b>default:</b> <code>nil</code>
 </dd>
 
 </dl>
@@ -579,28 +712,31 @@ These configuration directives are applicable only when running via the rake tas
 
 We know that testing usually requires more than just the test framework, so we've included some of the libraries that we use on a regular basis.
 
-- [Sinon.JS](http://sinonjs.org) Standalone test spies, stubs and mocks for JavaScript. No dependencies, works with any unit testing framework.
-- [ChaiJS](http://chaijs.com/) BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.
-- [expect.js](https://github.com/LearnBoost/expect.js) Minimalistic BDD assertion toolkit based on should.js.
-- [jasmine-jquery.js](https://github.com/velesin/jasmine-jquery) A set of custom matchers for jQuery, and an API for handling HTML fixtures in your specs.
-- [angular-scenario.js](https://github.com/angular/angular.js) Angular test setup.
+- [Sinon.JS](http://sinonjs.org) (1.8.2) Standalone test spies, stubs and mocks for JavaScript. No dependencies, works with any unit testing framework. BSD Licence.
+- [ChaiJS](http://chaijs.com/) (1.8.1) BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework. MIT License.
+- [Sinon-Chai](https://github.com/domenic/sinon-chai) (1.0.0) Extends Chai with assertions for the Sinon.JS mocking framework. MIT-ish License.
+- [expect.js](https://github.com/LearnBoost/expect.js) (0.1.2) Minimalistic BDD assertion toolkit based on should.js. MIT License.
+- [jasmine-jquery-1.7.0.js](https://github.com/velesin/jasmine-jquery) (1.7.0) For Jasmine v1, A set of custom matchers for jQuery, and an API for handling HTML fixtures in your specs. MIT License.
+- [jasmine-jquery-2.0.0.js](https://github.com/velesin/jasmine-jquery) (2.0.0) For Jasmine v2, A set of custom matchers for jQuery, and an API for handling HTML fixtures in your specs. MIT License.
 
 You can require these files in your spec helper by using:
 
 ```javascript
-//=require support/sinon
-//=require support/chai
-//=require support/expect
-//=require support/jasmine-jquery
-//=require support/angular-scenario
+//= require support/sinon
+//= require support/chai
+//= require support/expect
+//= require support/jasmine-jquery-1.7.0
+//= require support/jasmine-jquery-2.0.0
 ```
 
 
 ## CI Support
 
-Teaspoon works great on CI setups. Add a line to execute Teaspoon (e.g. `bundle exec teaspoon`) in your CI config file. If you're using TravisCI or CircleCI it just works, but if you're using something else all you should need is to ensure phantomjs is installed.
+Teaspoon works great on CI setups, and we've spent a good amount of time on getting that good. There's a lot of information to go over with that topic, but here are some highlights.
 
-You can add teaspoon to the default rake tasks by clearing out the defaults (this is sometimes not required), and then adding teaspoon in the chain where you want. So with rspec and cucumber, you get the rspec specs running first, then the javascript specs, and then cucumber (or whatever integration specs you have). This is what I do personally, and then I don't have to do any CI setup.
+Add a line to execute Teaspoon (e.g. `bundle exec teaspoon`) in your CI config file. If you're using TravisCI or CircleCI it just works, but if you're using something else all you should need is to ensure PhantomJS is installed.
+
+Alternately, you can add Teaspoon to the default rake tasks by clearing out the defaults (not always required), and then add `:teaspoon` into the chain of tasks where you want.
 
 ```ruby
 Rake::Task['default'].prerequisites.clear
@@ -609,39 +745,25 @@ Rake::Task['default'].clear
 task default: [:spec, :teaspoon, :cucumber]
 ```
 
-If you want to generate reports that CI can use you can install istanbul for coverage reports -- and output the report using the cobertura format, which Hudson can read.
-
-Again on hudson compatibile CI setups, you can track spec failure information/rate tracking by using the tap formatter, which can be parsed by hudson.
+If you want to generate reports that CI can use you can install Istanbul for coverage reports -- and output the report using the cobertura format, which Hudson and some others can read. You can track spec failure rates by using the tap formatter, or on TeamCity setups you can use the teamcity formatter. A junit formatter is available as well.
 
-A good setup:
+We encourage you to experiment and let us know. Feel free to create a wiki article about what you did to get it working on your CI setup.
 
-```
-teaspoon -q --coverage-reports=cobertura --format=tap
-```
 
-Or using Rake/ENV:
+## Alternative Projects
 
-```
-SUPPRESS_LOG=true COVERAGE_REPORTS=cobertura FORMATTERS=tap rake
-```
+[Konacha](https://github.com/jfirebaugh/konacha)
+[Jasminerice](https://github.com/bradphelan/jasminerice)
+[Evergreen](https://github.com/abepetrillo/evergreen)
+[jasmine-rails](https://github.com/searls/jasmine-rails)
+[guard-jasmine](https://github.com/netzpirat/guard-jasmine)
 
-There is also a TeamCity formatter:
-
-```
-teaspoon -q --format=teamcity
-```
-
-Or using Rake/ENV:
-
-```
-SUPPRESS_LOG=true FORMATTERS=teamcity rake
-```
 
 ## License
 
 Licensed under the [MIT License](http://creativecommons.org/licenses/MIT/)
 
-Copyright 2012 [Mode Set](https://github.com/modeset)
+Copyright 2014 [Mode Set](https://github.com/modeset)
 
 All licenses for the [bundled Javascript libraries](https://github.com/modeset/teaspoon/tree/master/vendor/assets/javascripts) are included (MIT/BSD).