Unless we're using the booth assignment for something else in the test,
when creating a voter from booth, specifying the poll and the booth is
enough to create a booth assignment.
Note we usually cannot make it simple because officer assignments are
usually assigned to both a poll and a booth, and on a certain date.
However, in the few cases where the booth nor the date don't matter, we
can make the code a bit easier to read.
While it could be argued we're hiding the real way we've defined
associations in our models, the tests are so much easier to read when we
don't have so many lines just creating data.
Furthermore, developers who care about vertically aligning the code will
be glad to see some variables disrupting this alignment are now gone.
We barely use this trait. In the votation type spec we're probably using
it wrong, and in the answer spec we assume one of the answers is going
to be "Yes".
The name `yes_no` is more expressive, since it makes it clear what the
answers are.
System count isn't a relevant number because the important one is the
number of votes counted by poll officers. We're still maintaining it for
a month in case poll officers would like to review the results.
Adding the option to assign a poll to a poll recount factory meant we
didn't need to create so much data.
Also note we're removing the `create(:poll_voter, origin: "booth")`
code, since it isn't used in the stats calculations.
The factories were creating strange database relations:
* The voter belonged to a poll, to a booth and to an officer
* The booth belonged to a different poll
* The officer belonged to a different booth
The code uses an unusual syntax because the following code:
association :booth_assignment,
factory: :poll_booth_assignment,
poll: poll
Would generate the following error:
ActiveRecord::AssociationTypeMismatch: Poll(#46976420451940) expected,
got FactoryBot::Declaration::Implicit
