kotovalexarian-likes-github/thoughtbot--shoulda-matchers
1
0
Fork 0
mirror of https://github.com/thoughtbot/shoulda-matchers.git synced 2022-11-09 12:01:38 -05:00
Code Releases Activity
thoughtbot--shoulda-matchers/lib/shoulda/matchers.rb

25 lines
668 B
Ruby
Raw Normal View History

Remove auto-detection of Rails / test framework
2014-10-22 20:54:36 -04:00
require 'shoulda/matchers/configuration'
Add a small stubbing library This provides a robust solution for temporarily stubbing (and unstubbing) methods. It will be internally by the strong parameters and delegation matchers.
2014-04-19 20:01:22 -04:00
require 'shoulda/matchers/doublespeak'
Handle ensure_inclusion_of for boolean columns Currently, using `ensure_inclusion_of` against a boolean column doesn't work. We can assert that the column allows boolean values, but what about values that should be rejected? Well, it depends on what you give to `ensure_inclusion_of`. Here's how it works now: * `ensure_inclusion_of(:attr).in_array([true])` asserts that false is rejected * `ensure_inclusion_of(:attr).in_array([false])` asserts that true is rejected * `ensure_inclusion_of(:attr).in_array([true, false])` does not assert that anything is rejected, instead informing the developer how this sort of expectation is not fully testable (anything other than true, false, or nil will be converted to false). * `ensure_inclusion_of(:attr).in_array([nil])`, when the column is nullable, does not assert that anything is rejected, either, also printing a warning * `ensure_inclusion_of(:attr).in_array([nil])`, when the column is non-nullable, raises an error because this expectation is not testable in any way, as setting a boolean column to nil this way will get converted to false.
2014-01-21 18:46:23 -05:00
require 'shoulda/matchers/error'
Remove auto-detection of Rails / test framework
2014-10-22 20:54:36 -04:00
require 'shoulda/matchers/independent'
require 'shoulda/matchers/integrations'
Fix delegate_method when used with shoulda-context When specifying a custom subject, a straightforward usage of `delegate_method`, such as the following class UserPresenter delegate :id, to: :user attr_reader :user def initialize(user) @user = user end end class UserPresenterTest < ActiveSupport::TestCase subject { UserPresenter.new(User.new) } should delegate_method(:id).to(:user) end would error with something like: ArgumentError: wrong number of arguments (0 for 1) This happens because the `should` method in shoulda-context asks the DelegateMethodMatcher object for its description so that it can use it to give the test a name and create a method that Test::Unit can run. Now, the matcher's description needs a subject in order to determine whether a class or an instance is being tested here -- if a class is being tested the description will be "should delegate #id to \#user object", if a class then "should delegate .id to .user object". Unfortunately the matcher doesn't know what the subject is before its #description method is called -- it only knows about this when it gets evaluated. Within the matcher we do have access to the current context class, so we could read the subject block off of it and evaluate it. However, in order to properly do this we also need access to the instance of the test itself, which we do not have until the matcher is evaluated (by which point it's too late). Since there's really no way to solve this problem apart from rewriting a lot of shoulda-context, and since often times your subject is an instance and not a class, just assume it's an instance in this case.
2014-09-12 18:39:48 -04:00
require 'shoulda/matchers/matcher_context'
Fix render_with_layout_matcher on Rails 4. Rails 4 moved the layouts ivar from `@layouts` to `@_layouts`. This change introduces what I have (for now) called the 'RailsShim'. The idea is that this single class will house the rail version workarounds, which can then be reused through the code. This paid off here because both the spec and the implementation need access to the layouts ivar.
2013-05-10 14:10:46 -04:00
require 'shoulda/matchers/rails_shim'
Fix define_class/model to support namespaces You can now say `define_class('Models::User')` and it will define a User class inside of the Models module. Similarly, you can also say `define_model('Models::User')` and it will set the table name of the model to `models_users` instead of just `users`.
2014-10-08 01:19:07 -04:00
require 'shoulda/matchers/util'
Handle ensure_inclusion_of for boolean columns Currently, using `ensure_inclusion_of` against a boolean column doesn't work. We can assert that the column allows boolean values, but what about values that should be rejected? Well, it depends on what you give to `ensure_inclusion_of`. Here's how it works now: * `ensure_inclusion_of(:attr).in_array([true])` asserts that false is rejected * `ensure_inclusion_of(:attr).in_array([false])` asserts that true is rejected * `ensure_inclusion_of(:attr).in_array([true, false])` does not assert that anything is rejected, instead informing the developer how this sort of expectation is not fully testable (anything other than true, false, or nil will be converted to false). * `ensure_inclusion_of(:attr).in_array([nil])`, when the column is nullable, does not assert that anything is rejected, either, also printing a warning * `ensure_inclusion_of(:attr).in_array([nil])`, when the column is non-nullable, raises an error because this expectation is not testable in any way, as setting a boolean column to nil this way will get converted to false.
2014-01-21 18:46:23 -05:00
require 'shoulda/matchers/version'
Fix delegate_method when used with shoulda-context When specifying a custom subject, a straightforward usage of `delegate_method`, such as the following class UserPresenter delegate :id, to: :user attr_reader :user def initialize(user) @user = user end end class UserPresenterTest < ActiveSupport::TestCase subject { UserPresenter.new(User.new) } should delegate_method(:id).to(:user) end would error with something like: ArgumentError: wrong number of arguments (0 for 1) This happens because the `should` method in shoulda-context asks the DelegateMethodMatcher object for its description so that it can use it to give the test a name and create a method that Test::Unit can run. Now, the matcher's description needs a subject in order to determine whether a class or an instance is being tested here -- if a class is being tested the description will be "should delegate #id to \#user object", if a class then "should delegate .id to .user object". Unfortunately the matcher doesn't know what the subject is before its #description method is called -- it only knows about this when it gets evaluated. Within the matcher we do have access to the current context class, so we could read the subject block off of it and evaluate it. However, in order to properly do this we also need access to the instance of the test itself, which we do not have until the matcher is evaluated (by which point it's too late). Since there's really no way to solve this problem apart from rewriting a lot of shoulda-context, and since often times your subject is an instance and not a class, just assume it's an instance in this case.
2014-09-12 18:39:48 -04:00
require 'shoulda/matchers/warn'
Switched to allowing a more canonical require statement require "shoulda/matchers" # canonical -vs- require "shoulda-matchers" # still allowed See comments of http://blog.segment7.net/2010/11/15/how-to-name-gems
2011-01-31 16:30:31 -05:00
Remove auto-detection of Rails / test framework
2014-10-22 20:54:36 -04:00
require 'shoulda/matchers/action_controller'
require 'shoulda/matchers/active_model'
require 'shoulda/matchers/active_record'
Add a new Routing module Why: * The `route` matcher can not only be used within controller example groups but also routing example groups. * Now that we are mixing matchers into specific example groups, `route` is no longer available in routing example groups. To satisfy the above: * Create a new module that contains a `route` method and returns a new instance of RouteMatcher. (RouteMatcher still lives in the ActionController namespace.) * Mix this module into routing example groups when the gem configuration block is run.
2015-09-24 16:09:35 -04:00
require 'shoulda/matchers/routing'
Remove warning under Minitest 5 Under Minitest 5 (or a Rails 4.1 project), you will get a warning MiniTest::Unit::TestCase is now Minitest::Test. when you attempt to run tests. This is because shoulda-matchers requires 'test/unit/testcase', even if Test::Unit is not being used. It is not a good idea for shoulda-matchers to require *anything* that the user may not be using, whether it's Test::Unit or RSpec. We should assume that by the time shoulda-matchers is required, the user has already required all of whatever test framework they are using, not none or even some of that framework.
2014-04-04 17:02:18 -04:00
Remove auto-detection of Rails / test framework
2014-10-22 20:54:36 -04:00
module Shoulda
module Matchers
class << self
Omit newest private modules from docs [ci skip]
2015-03-01 03:20:41 -05:00
# @private
Remove auto-detection of Rails / test framework
2014-10-22 20:54:36 -04:00
attr_accessor :assertion_exception_class
end
end
Remove warning under Minitest 5 Under Minitest 5 (or a Rails 4.1 project), you will get a warning MiniTest::Unit::TestCase is now Minitest::Test. when you attempt to run tests. This is because shoulda-matchers requires 'test/unit/testcase', even if Test::Unit is not being used. It is not a good idea for shoulda-matchers to require *anything* that the user may not be using, whether it's Test::Unit or RSpec. We should assume that by the time shoulda-matchers is required, the user has already required all of whatever test framework they are using, not none or even some of that framework.
2014-04-04 17:02:18 -04:00
end
Copy permalink