I'd like to improve specs for a convenience method that returns an array of users whose purchases are due tomorrow and will be paid using a certain payment method (ignoring other payment methods).
The specs are something along the lines of:
it "doesn't return users without purchases being due tomorrow" do
# create user and associated records that don't fit the time condition
expect(subject).to eq([])
end
context "with users who have purchases due tomorrow" do
it "returns users with $CERTAIN_PAYMENT_METHOD" do
# create different users with different payment methods,
# all matching the time condition.
expect(subject).to eq([user_1, user_2])
end
it "doesn't return users without $CERTAIN_PAYMENT_METHOD" do
# create user with credit card,
# matching the time condition.
expect(subject).to eq([])
end
end
I see three possible approaches here:
- Approach used above: Set up arbitrary combinations of records, and expect things specific to a single condition, always asserting the whole array. The setup can be long and repetitive.
- Set up arbitrary combinations, and expect things to be included/excluded in the returned array. These "soft expectations" are great to read but can be very error-prone.
- Set up (nearly) all combinations of records, and have a single expectation. This creates no overlap but also leaves developers in the dark as to why this method returns this specific array.
All approaches have their drawbacks, and I'm wondering if there's a best practice how to test methods like these?
Aucun commentaire:
Enregistrer un commentaire