diff options
| -rw-r--r-- | actionpack/lib/abstract_controller/callbacks.rb | 10 | ||||
| -rw-r--r-- | actionview/lib/action_view/renderer/renderer.rb | 2 | ||||
| -rw-r--r-- | guides/source/testing.md | 26 |
3 files changed, 30 insertions, 8 deletions
diff --git a/actionpack/lib/abstract_controller/callbacks.rb b/actionpack/lib/abstract_controller/callbacks.rb index 287550db42..d5317e4717 100644 --- a/actionpack/lib/abstract_controller/callbacks.rb +++ b/actionpack/lib/abstract_controller/callbacks.rb @@ -39,8 +39,8 @@ module AbstractController # except: :index, if: -> { true } # the :except option will be ignored. # # ==== Options - # * <tt>only</tt> - The callback should be run only for this action - # * <tt>except</tt> - The callback should be run for all actions except this action + # * <tt>only</tt> - The callback should be run only for this action. + # * <tt>except</tt> - The callback should be run for all actions except this action. def _normalize_callback_options(options) _normalize_callback_option(options, :only, :if) _normalize_callback_option(options, :except, :unless) @@ -59,7 +59,7 @@ module AbstractController # * <tt>names</tt> - A list of valid names that could be used for # callbacks. Note that skipping uses Ruby equality, so it's # impossible to skip a callback defined using an anonymous proc - # using #skip_action_callback + # using #skip_action_callback. def skip_action_callback(*names) ActiveSupport::Deprecation.warn('`skip_action_callback` is deprecated and will be removed in Rails 5.1. Please use skip_before_action, skip_after_action or skip_around_action instead.') skip_before_action(*names, raise: false) @@ -82,8 +82,8 @@ module AbstractController # * <tt>block</tt> - A proc that should be added to the callbacks. # # ==== Block Parameters - # * <tt>name</tt> - The callback to be added - # * <tt>options</tt> - A hash of options to be used when adding the callback + # * <tt>name</tt> - The callback to be added. + # * <tt>options</tt> - A hash of options to be used when adding the callback. def _insert_callbacks(callbacks, block = nil) options = callbacks.extract_options! _normalize_callback_options(options) diff --git a/actionview/lib/action_view/renderer/renderer.rb b/actionview/lib/action_view/renderer/renderer.rb index 1bee35d80d..2a3b89aebf 100644 --- a/actionview/lib/action_view/renderer/renderer.rb +++ b/actionview/lib/action_view/renderer/renderer.rb @@ -15,7 +15,7 @@ module ActionView @lookup_context = lookup_context end - # Main render entry point shared by AV and AC. + # Main render entry point shared by Action View and Action Controller. def render(context, options) if options.key?(:partial) render_partial(context, options) diff --git a/guides/source/testing.md b/guides/source/testing.md index 2f941a8280..f63ea49955 100644 --- a/guides/source/testing.md +++ b/guides/source/testing.md @@ -155,7 +155,7 @@ Failed assertion, no message given. 1 tests, 1 assertions, 1 failures, 0 errors, 0 skips ``` -In the output, `F` denotes a failure. You can see the corresponding trace shown under `1)` along with the name of the failing test. The next few lines contain the stack trace followed by a message which mentions the actual value and the expected value by the assertion. The default assertion messages provide just enough information to help pinpoint the error. To make the assertion failure message more readable, every assertion provides an optional message parameter, as shown here: +In the output, `F` denotes a failure. You can see the corresponding trace shown under `1)` along with the name of the failing test. The next few lines contain the stack trace followed by a message that mentions the actual value and the expected value by the assertion. The default assertion messages provide just enough information to help pinpoint the error. To make the assertion failure message more readable, every assertion provides an optional message parameter, as shown here: ```ruby test "should not save article without title" do @@ -523,7 +523,7 @@ Model tests don't have their own superclass like `ActionMailer::TestCase` instea Integration Testing ------------------- -Integration tests are used to test how various parts of your application interact. They are generally used to test important work flows within your application. +Integration tests are used to test how various parts of your application interact. They are generally used to test important workflows within your application. For creating Rails integration tests, we use the 'test/integration' directory for your application. Rails provides a generator to create an integration test skeleton for you. @@ -1232,3 +1232,25 @@ class ProductTest < ActiveJob::TestCase end end ``` + +Testing Time-Dependent Code +--------------------------- + +Rails provides inbuilt helper methods that enable you to assert that your time-sensitve code works as expected. + +Here is an example using the [`travel_to`](http://api.rubyonrails.org/classes/ActiveSupport/Testing/TimeHelpers.html#method-i-travel_to) helper: + +```ruby +# Lets say that a user is eligible for gifting a month after they register. +user = User.create(name: 'Gaurish', activation_date: Date.new(2004, 10, 24)) +assert_not user.applicable_for_gifting? +travel_to Date.new(2004, 11, 24) do + assert_equal Date.new(2004, 10, 24), user.activation_date # inside the travel_to block `Date.current` is mocked + assert user.applicable_for_gifting? +end +assert_equal Date.new(2004, 10, 24), user.activation_date # The change was visible only inside the `travel_to` block. +``` + +Please see [`ActiveSupport::TimeHelpers` API Documentation](http://api.rubyonrails.org/classes/ActiveSupport/Testing/TimeHelpers.html) +for in-depth information about the available time helpers. + |