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.
We were expecting the page not to have content which is actually there.
The test passed (most of the time) because before clicking the
"Milestones" link the content was not present, and we checked the page
content before the AJAX request generated by clicking the link had
finished.
Since we removed the `best_in_place` gem, this method doesn't exist
anymore. We're replacing it with what the method actually does.
Note the test doesn't check the poll is correctly updated. We could add
a `visit proposal_dashboard_polls_path(proposal)` before checking the
"Show results" field, but then we would enter a race condition between
this request and the AJAX request. A proper solution would be to provide
actual feedback to the user so they know the poll has been updated, and
then checking that feedback is present in the tests.
