These variables can be considered a block, and so removing them doesn't
make the test much harder to undestand.
Sometimes these variables formed the setup, sometimes they formed an
isolated part of the setup, and sometimes they were the part of the test
that made the test different from other tests.
The instance variable was being evaluated to `nil`, and the budget was
automatically created by the `set_denormalized_ids` method in the budget
investment class.
Date.new(...) does not take into account the current timezone, while other
parts of the application do. By default always parsing any date with the
default timezone and converting the resulting Time to Date would prevent
this kind of issues
DateTime.parse(...).in_time_zone gives an unexpected result, as the
DateTime.parse(...) will create a DateTime with +0000 time zone and the
`in_time_zone` will modify the DateTime to adjust to the default zone.
Maybe its better explained with an example, using 'Lima' as timezone:
DateTime.parse("2015-01-01")
> Thu, 01 Jan 2015 00:00:00 +0000
DateTime.parse("2015-01-01").in_time_zone
> Wed, 31 Dec 2014 19:00:00 -05 -05:00
And that's not the desired date but the previous day!
