This implementation is a bit more robust because we don't have to change
any of the "or_later?" methods if we add or remove a new phase.
We could also use metaprogramming to reduce code duplication in these
methods. So far, I've decided to keep the code simple since the
duplication seems reasonable.
So if we don't have information regarding gender, age or geozone, stats
regarding those topics will not be shown.
Note we're using `spec/models/statisticable_spec.rb` because having the
same file in `spec/models/concerns` caused the tests to be executed
twice.
Also note the implementation behind the `gender?`, `age?` and `geozone?`
methods is a bit primitive. We might need to make it more robust in the
future.
It will make it far easier to call other methods on the stats object,
and we're already caching the methods.
We had to remove the view fragment caching because the stats object
isn't as easy to cache. The good thing about it is the view will
automatically be updated when we change logic regarding which stats to
show, and the methods taking long to execute are cached in the model.
For now we think showing them would be showing too much data and it
would be a bit confusing.
I've been tempted to just remove the view and keep the methods in the
model in case they're used by other institutions using CONSUL. However,
it's probably better to wait until we're asked to re-implement them, and
in the meantime we don't maintain code nobody uses. The code wasn't that
great to start with (I know it because I wrote it).
We were expecting `balloters` to include `poll_ballot_voters` (that's
why we're substracting them to calculate web participants), but reality
has proven `poll_ballot_voters` aren't included in `balloters`.
While we already had "one test to rule all stats", testing each method
individually makes reading, adding and changing tests easier.
Note we need to make all methods being tested public. We could also test
them using methods like `stats.generate[:total_valid_votes]` instead of
`stats.total_valid_votes`, but then the tests would be more difficult to
read.
This spec was leaving the DB "dirty" because it was creating
records in a before(:all) hook. These records are not cleaned up
automatically when using the :transaction strategy for DatabaseCleaner.
Using before(:each), however, causes another problem. Some of the code
depends on the heading id being 1 (see app/models/budget/ballot/line.rb#L48).
Because of SQL auto-increment, this is only the case the first time the hook
is run, as different id's are assigned on subsequent runs. This is fixed
by forcing the id to always be 1.
This code was introduced in commit 722a431b, but it stopped being used
in commit 7657a0e0.
The spec was failing sometimes because the method didn't order the
records, but the spec checked the records returned in a certain order.
Furthermore, the method `page` generated a potential conflict with
kaminari's `page method.
If tests run very fast all votes are created within the last 24
hours, so hot_score has the same value if the creation date for the
votes is Time.current or 1.day.ago.
Creating the votes 48 hours ago we make sure hot_score has the
correct value and the tests pass correctly.
This section is used to select to which poll a question belongs to.
Budget polls are not meant to include questions that come from Citizen
Proposals or Government Questions, thus we do not display them
This way we can easily add a test which will fail if by accident we
change the method to use `Date.today`. Until now using `Date.today`
would only fail if we ran specs in a time zone with a different date.
