This is an effort to vastly decrease the time it takes to run a single
unit test file and therefore increase productivity and happiness for
people working on this project.
If you want to run a unit test file, now you can use `zeus rspec`
instead of `rspec` -- assuming you run `zeus start` first -- and it will
run a LOT faster.
Because test files tend to have long file paths, you can even use a
shorter version of those paths. So instead of saying:
zeus rspec spec/unit/shoulda/matchers/active_record/validate_uniqueness_of_matcher_spec.rb
you can say:
zeus rspec active_record/validate_uniqueness_of_matcher_spec.rb
Why:
* At some point a while back, Appraisal introduced a bug fix that made
it possible to run `rspec` through `appraisal` and pass the `-e`
option to target certain tests. This makes life much easier.
* It's been a while since we've upgraded Appraisal anyway.
The latest commit of pry removes a lot of annoying warnings.
Unfortunately a new release has not been issued yet, so just use the
master branch for now.
When running tests, you can now switch between running them against a
SQLite or PostgreSQL database. This is accomplished by modifying the
unit and acceptance tests so that when they generate and load the test
Rails application, database.yml is replaced with content that will
configure the database appropriately.
Secondary author: Luciano Sousa <ls@lucianosousa.net>
Also, upgrade to rspec-rails 3.2.0 explicitly. (See
b7fe87ae91 for an explanation of why 3.2.0
is necessary here.)
* Remove Aruba and Bourne since we don't use them anymore
* Remove Rails from main Gemfile as it's already a dependency in each of
the appraisals
* Tighten dependency on Rake to 10.x
* Move dependencies shared among appraisals to Appraisals
* Ruby 2.2 removed Minitest and Test::Unit from the standard library
[[1]], [[2]]
* rspec-rails requires Test::Unit for Rails versions prior to 4.1 (which
switched to Minitest)
* This doesn't work now, because we don't have Test::Unit present in the
gem bundle
* RSpec 3.2.0 fixes this issue [[3]]
I don't really see this as a huge concern, since we were testing against
RSpec 2.99 for Rails < 4, and that has most of the changes that RSpec 3
has.
[1]: f8c6a5dc02
[2]: 96f552670d
[3]: 999ebb7c5c (diff-08d960c572ac094640dd183fa9641393R13)
Currently before running unit tests we are getting auto-required before
rspec-rails is getting required. This is bad because we need to wait
until rspec-rails is loaded before injecting Shoulda::Matchers::* into
the current RSpec context, otherwise matchers that clash with
rspec-rails (such as `render_template` will get overridden).
This is happening when creating and booting the Rails application.
Bundler will auto-require any gems in the Gemfile. One of these gems is
ourselves (via the `gemspec` line). Since there aren't any dependencies
in the gemspec, there's no need for us to be in the Gemfile.
This means that we no longer have to explicit `include` Rails
ActionController template assertions in the tests for `render_template`
as they should get included automatically for us.
Given this scenario:
* Using Rails 4.1
* Gemfile has `gem 'shoulda-matchers', require: false`
* spec_helper has `require 'shoulda/matchers'` following
`require 'rspec/rails'`
* Using Spring to run tests
matchers that delegate to assertions in Rails (e.g. `render_template`
and `route`) will fail in the wrong way if used. They fail because in
order to use these assertions, we expect that the assertions will
raise a specific exception, an exception that corresponds to whichever
test framework that Rails is using. For Rails versions that used
Test::Unit, this is Test::Unit::AssertionFailedError. For current Rails
versions, which now use Minitest, this exception is Minitest::Assertion.
The problem is that instead of asking Rails which exception class it's
using, we are trying to detect this exception class ourselves (for
cases in which Rails is not being used). This leads to the wrong class
being detected: when using a Rails version that uses Minitest, we choose
Test::Unit::AssertionFailedError as the class. This happens using the
exact scenario above because even though shoulda-matchers is loaded
after rspec-rails, rspec-rails itself defines
Test::Unit::AssertionFailedError.
Also add Cucumber tests that confirms this exact scenario works.
Currently some dev dependencies are in the Gemfile, and some are in the
gemspec. The dependencies in the Gemfile are there because they are
using Bundler-specific options, so there is a legitimate reason for them
to be there, however, it's confusing to have gems in two places. So the
common denominator is to have them in the Gemfile.
Since as of commit 2748b75087, we no
longer install dependencies inside of the Rails app that is generated
and used to run all of the tests, we have to require all of the
dependencies that the app would install inside of the appropriate
Appraisals.
This was mostly straightforward except for some workarounds with the
turn gem:
* Rails 3.1 requires two versions of turn depending on which Ruby
version you're using. On 1.9.2, it uses turn 0.9.2; after 1.9.2, it
uses ~> 0.9.3. To accommodate this we have to have two versions of the
Rails 3.1 appraisal which declare the different turn versions.
* Rails 3.1 also loads the turn gem even if, in the Gemfile for the app,
turn is declared with `require: false`. This causes a problem while
running our tests because turn actually requires minitest/autorun,
which adds a hook so when Ruby exits, Minitest tests are run. Because
we're already using RSpec, Minitest will try to re-run the `rspec`
command we ran within a Minitest environment. This will fail since we
are using RSpec-specific command line options to run the tests.
Unfortunately there's no way to shut off minitest/autorun after it's
been required, so we have to monkey-patch Minitest's #run method so
it's a no-op.
