Before:
```
$ bundle exec rspec -e ".render_as"
(...)
Run options: include {:full_description=>/\.render_as/}
WARNING: Using the `raise_error` matcher without providing a specific error or message risks false positives, since `raise_error` will match when Ruby raises a `NoMethodError`, `NameError` or `ArgumentError`, potentially allowing the expectation to pass without even executing the method you are intending to call. Actual error raised was #<ActionController::BadRequest: report_format should be in [:csv, :json, :html, :xlsx, :pdf]>. Instead consider providing a specific error class or message. This message can be suppressed by setting: `RSpec::Expectations.configuration.on_potential_false_positives = :nothing`. Called from /path/to/spec/lib/reports/report_renderer_spec.rb:34:in `block (3 levels) in <main>'.
.
Finished in 0.02544 seconds (files took 4.08 seconds to load)
1 example, 0 failures
```
After this patch:
```
$ bundle exec rspec -e ".render_as"
(...)
Run options: include {:full_description=>/\.render_as/}
.
Finished in 0.02488 seconds (files took 4.09 seconds to load)
1 example, 0 failures
```
Rails 4.1 added time helpers but we never bothered using them. But now
I'm getting rid of the Timecop dependency and use standard helpers.
Beware though that the new helpers always freeze time. When you travel
to a certain date then the clock stops ticking while Timecop maintained
the passing of time.
The freezing of time could cause problems if you are trying to enforce a
timeout. But all current specs don't seem affected.
In most cases, the freezing will make it easier to avoid flaky specs.
The string '< Hidden >' was agreed on as a good default, so we will use the hidden_field key.
I also moved the definition in en.yml up to the more general area at the start of admin.reports section (before it was hidden between report-specific keys.
when permitted.
The MaskDataService is used by the report framework, so this should affect all reports. It would be nice to test all reports, but I figured it wasn't worth it (already we only test one report for masking names).
The privileges of a user should never change within a request
life cycle. The `spree_roles` association is very small, between 0 and 2
items are quickly searched in memory without the need of additional
database queries.
From memory, I've seen a lot of spree_roles queries in log files per
request. This should reduce it to one.