ActiveSupport::Testing::Assertions.
We have a separate module in which have defined Rails' own custom
assertions. So it would be good to keep all custom Rails' assertions in
one place i.e. in this module.
A performance regression was introduced by commit b79adc4323ff289aed3f5787fdfbb9542aa4f89f
from Rails 4.0.0.beta1, in which `TimeWithZone#to_time` no longer returns a
cached instance attribute but instead coerces the value to `Time`. This
coerced value is not cached, and recomputation degrades the performance
of comparisons between TimeWithZone objects.
See b79adc4323 (diff-3497a506c921a3a3e40fd517e92e4fe3R322)
for the change in question.
The following benchmark, which reverts the change linked above, demonstrates
the performance regression:
require 'active_support/time'
require 'benchmark/ips'
utc = Time.utc(2000, 1, 1, 0)
time_zone = ActiveSupport::TimeZone['Eastern Time (US & Canada)']
twz = ActiveSupport::TimeWithZone.new(utc, time_zone)
twz2 = ActiveSupport::TimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC'])
patchedTimeWithZone = Class.new(ActiveSupport::TimeWithZone) do
def to_time
utc
end
end
patched_twz = patchedTimeWithZone.new(utc, time_zone)
patched_twz2 = patchedTimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC'])
Benchmark.ips do |x|
x.report("comparison out of the box") { twz <=> twz2 }
x.report("comparison reverting to_time") { patched_twz <=> patched_twz2 }
x.compare!
end
The results, when run in rails-dev-box, are as follows:
Warming up --------------------------------------
comparison out of the box
24.765k i/100ms
comparison reverting to_time
57.237k i/100ms
Calculating -------------------------------------
comparison out of the box
517.245k (± 4.7%) i/s - 2.600M in 5.038700s
comparison reverting to_time
2.624M (± 5.0%) i/s - 13.050M in 4.985808s
Comparison:
comparison reverting to_time: 2624266.1 i/s
comparison out of the box: 517244.6 i/s - 5.07x slower
The change made to run the benchmark, however, is not possible, as it would
undo the intent to standardize the return value of `to_time` to `Time` in
the system timezone.
Our proposed solution is to restore the caching behaviour of `to_time`
as it existed prior to the change linked above.
Benchmark of our solution:
require 'active_support/time'
require 'benchmark/ips'
patchedTimeWithZone = Class.new(ActiveSupport::TimeWithZone) do
def to_time
@to_time ||= super
end
end
utc = Time.utc(2000, 1, 1, 0)
time_zone = ActiveSupport::TimeZone['Eastern Time (US & Canada)']
twz = ActiveSupport::TimeWithZone.new(utc, time_zone)
twz2 = ActiveSupport::TimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC'])
patched_twz = patchedTimeWithZone.new(utc, time_zone)
patched_twz2 = patchedTimeWithZone.new(Time.utc(1999, 12, 31, 23, 59, 59), ActiveSupport::TimeZone['UTC'])
Benchmark.ips do |x|
x.report("TimeWithZone comparison - existing implementation") { twz <=> twz2 }
x.report("TimeWithZone comparison - caching implementation") { patched_twz <=> patched_twz2 }
x.compare!
end
Results in rails-dev-box:
Warming up --------------------------------------
TimeWithZone comparison - existing implementation
26.629k i/100ms
TimeWithZone comparison - caching implementation
59.144k i/100ms
Calculating -------------------------------------
TimeWithZone comparison - existing implementation
489.757k (± 4.2%) i/s - 2.450M in 5.011639s
TimeWithZone comparison - caching implementation
2.802M (± 5.3%) i/s - 13.958M in 4.996116s
Comparison:
TimeWithZone comparison - caching implementation: 2801519.1 i/s
TimeWithZone comparison - existing implementation: 489756.7 i/s - 5.72x slower
This code has too much duplication and the rationale for the concatenation
may not be obvious to the reader. You define the ones at class-level, explain
why does the code concatenates there, and then the convenience ones at
instance-level just delegate.
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
The current implementation of `thread_mattr_accessor` set variable
sharing superclass with subclass. So the method doesn't work as documented.
Precondition
class Account
thread_mattr_accessor :user
end
class Customer < Account
end
Account.user = "DHH"
Account.user #=> "DHH"
Customer.user = "Rafael"
Customer.user # => "Rafael"
Documented behavior
Account.user # => "DHH"
Actual behavior
Account.user # => "Rafael"
Current implementation set variable statically likes `Thread[:attr_Account_user]`,
and customer also use it.
Make variable name dynamic to use own thread-local variable.
Since 434df00 week durations are no longer converted to days. This means
we need to add :weeks to the parts that ActiveSupport::TimeWithZone will
consider being of variable duration to take account of DST transitions.
Fixes#26039.
AEAD modes like `aes-256-gcm` provide both confidentiality and data authenticity, eliminating the need to use MessageVerifier to check if the encrypted data has been tampered with.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
Those are assertions that I really do miss from the standard
`ActiveSupport::TestCase`. Think of those as a more general version of
`assert_difference` and `assert_no_difference` (those can be implemented
by assert_changes, should this change be accepted).
Why do we need those? They are useful when you want to check a
side-effect of an operation. `assert_difference` do cover a really
common case, but we `assert_changes` gives us more control. Having a
global error flag? You can test it easily with `assert_changes`. In
fact, you can be really specific about the initial state and the
terminal one.
```ruby
error = Error.new(:bad)
assert_changes -> { Error.current }, from: nil, to: error do
expected_bad_operation
end
```
`assert_changes` follows `assert_difference` and a string can be given
for evaluation as well.
```ruby
error = Error.new(:bad)
assert_changes 'Error.current', from: nil, to: error do
expected_bad_operation
end
```
Check out the test cases if you wanna see more examples.
🍻
The minitest stubs were conflicting with the time travel stubs so the
travel_back method call in the teardown block was actually keeping the
time stubbed.
This test was added to protect the test suite from our mistakes but now
it is failing because bundler does add duplicated libs in the load path
by design (if the repository has more than one gem)
Fix for issue https://github.com/rails/rails/issues/25784
Prior to this commit the lazy_load_hooks.rb file contained important lazy load
hooks. Since [7c90d91](7c90d91c3c) the [documentation](http://api.rubyonrails.org/files/activesupport/lib/active_support/lazy_load_hooks_rb.html) did not display
the comments in this file as the docs for load hooks.
This commit wraps the code within this file in a module so we can display the
documentation for `ActiveSupport` load hooks. By extending `ActiveSupport` with
this module, all the methods within it should still be accessible through
`ActiveSupport`.
The current implementation serializes zero-length durations incorrectly (it serializes as `"-P"`), and cannot un-serialize itself:
```
[1] pry(main)> ActiveSupport::Duration.parse(0.minutes.iso8601)
ActiveSupport::Duration::ISO8601Parser::ParsingError: Invalid ISO 8601 duration: "-P" is empty duration
from /Users/rando/.gem/ruby/2.3.1/gems/activesupport-5.0.0/lib/active_support/duration/iso8601_parser.rb:96:in `raise_parsing_error'
```
Postgres empty intervals are serialized as `"PT0S"`, which is also parseable by the Duration deserializer, so I've modified the `ISO8601Serializer` to do the same.
Additionally, the `#normalize` function returned a negative sign if `parts` was blank (all zero). Even though this fix does not rely on the sign, I've gone ahead and corrected that, too, in case a future refactoring of `#serialize` uses it.
as this can lead to confusing time stubbing.
Instead of:
travel_to 2.days.from_now do
# 2 days from today
travel_to 3.days.from_now do
# 5 days from today
end
end
preferred way to achieve above is:
travel_to 2.days.from_now
# 2 days from today
travel_back
travel_to 5.days.from_now
# 5 days from today
Closes#24690Fixes#24689
KeyGenerator is used in other contexts, and we cannot change its
output... even if it does accidentally default to generating excess key
material for our primary internal usage.
ruby < 2.4 allowed accepting these values, as extra key bits were ignored. Since ce635262f5 this now has a strict checking on key length.
Default to key length 32 bytes, to match the compatible length for aes-256-cbc
Fixes#25185
When the Pathname object is converted as JSON,
it should be a string that means itself.
Expected:
```
>> Pathname.new('/path/to/somewhere.txt').as_json
"/path/to/somewhere.txt"
```
Actual:
```
>> Pathname.new('/path/to/somewhere.txt').as_json
{"path"=>"/path/to/somewhere.txt"}
```
When the URI object is converted as JSON,
it is expected that it is a string that means its URI.
Expected:
```
>> URI.parse('http://example.com').as_json
"http://example.com"
```
Actual:
```
>> URI.parse('http://example.com').as_json
{"scheme"=>"http",
"user"=>nil,
"password"=>nil,
"host"=>"example.com",
"port"=>80,
"path"=>"",
"query"=>nil,
"opaque"=>nil,
"fragment"=>nil,
"parser"=>
{"regexp"=>
{"SCHEME"=>"(?-mix:\\A[A-Za-z][A-Za-z0-9+\\-.]*\\z)",
"USERINFO"=>"(?-mix:\\A(?:%\\h\\h|[!$&-.0-;=A-Z_a-z~])*\\z)",
"HOST"=>
"(?-mix:\\A(?:(?<IP-literal>\\[(?:(?<IPv6address>(?:\\h{1,4}:){6}(?<ls32>\\h{1,4}:\\h{1,4}|(?<IPv4address>(?<dec-octet>[1-9]\\d|1\\d{2}|2[0-4]\\d|25[0-5]|\\d)\\.\\g<dec-octet>\\.\\g<dec-octet>\\.\\g<dec-octet>))|::(?:\\h{1,4}:){5}\\g<ls32>|\\h{,4}::(?:\\h{1,4}:){4}\\g<ls32>|(?:(?:\\h{1,4}:)?\\h{1,4})?::(?:\\h{1,4}:){3}\\g<ls32>|(?:(?:\\h{1,4}:){,2}\\h{1,4})?::(?:\\h{1,4}:){2}\\g<ls32>|(?:(?:\\h{1,4}:){,3}\\h{1,4})?::\\h{1,4}:\\g<ls32>|(?:(?:\\h{1,4}:){,4}\\h{1,4})?::\\g<ls32>|(?:(?:\\h{1,4}:){,5}\\h{1,4})?::\\h{1,4}|(?:(?:\\h{1,4}:){,6}\\h{1,4})?::)|(?<IPvFuture>v\\h+\\.[!$&-.0-;=A-Z_a-z~]+))\\])|\\g<IPv4address>|(?<reg-name>(?:%\\h\\h|[!$&-.0-9;=A-Z_a-z~])*))\\z)",
"ABS_PATH"=>
"(?-mix:\\A\\/(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~])*(?:\\/(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~])*)*\\z)",
"REL_PATH"=>
"(?-mix:\\A(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~])+(?:\\/(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~])*)*\\z)",
"QUERY"=>"(?-mix:\\A(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~\\/?])*\\z)",
"FRAGMENT"=>"(?-mix:\\A(?:%\\h\\h|[!$&-.0-;=@-Z_a-z~\\/?])*\\z)",
"OPAQUE"=>"(?-mix:\\A(?:[^\\/].*)?\\z)",
"PORT"=>
"(?-mix:\\A[\\x09\\x0a\\x0c\\x0d ]*\\d*[\\x09\\x0a\\x0c\\x0d ]*\\z)"}}}
```
Time.new is a Ruby method that uses system timezone. Traveling in time
using it is a recipe for confusion. Instead, Time.zone.local should
be used since it uses the Rails timezone.
