Fighting flakiness: no longer uses beCloseToDate in CustomerInfoOfflineEntitlementsStoreKitTest.verifyEntitlement
#4399
Conversation
…itTest.verifyEntitlement
| purchaseDate: Date(), | ||
| purchaseDate: transaction.purchaseDate, |
There was a problem hiding this comment.
Note that this is an actual implementation change. However, using the transaction date might be more correct? This was introduced in #2358, but there are no details on this particular property. Let me know if this is actually not what we want.
There was a problem hiding this comment.
Seems this is only used for offline entitlements and conceptually it makes sense. Also checked on Android and seems this is the logic we use there so I think it's ok...
But I would like someone from @RevenueCat/catforms to double-check.
There was a problem hiding this comment.
Thanks Toni! Hi @RevenueCat/catforms, could you have a quick look? 🙏
|
@RCGitBot please test |
|
@RCGitBot please test |
JayShortway
changed the title
beCloseToDate in CustomerInfoOfflineEntitlementsStoreKitTest.verifyEntitlementbeCloseToDate in CustomerInfoOfflineEntitlementsStoreKitTest.verifyEntitlement
| purchaseDate: Date(), | ||
| purchaseDate: transaction.purchaseDate, |
There was a problem hiding this comment.
Seems this is only used for offline entitlements and conceptually it makes sense. Also checked on Android and seems this is the logic we use there so I think it's ok...
But I would like someone from @RevenueCat/catforms to double-check.
I have seen that
beCloseToDate()/beCloseToNow()is one of our sources of flakiness. For instance, see the last test here. A hiccup in the CI server, an extra background process, a little bit more heat in the CircleCI data center, and things can take a fraction longer, causing this to fail.This PR makes the tests deterministic, by defining the exact date we expect. It only tackles
CustomerInfoOfflineEntitlementsStoreKitTest.verifyEntitlement()for now. More to come in later PRs.