-
Notifications
You must be signed in to change notification settings - Fork 121
[In-app Purchases] Add unit tests for InAppPurchaseStore #8067
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Generated by 🚫 dangerJS |
| "_applicationInternalID" : "1389130815", | ||
| "_developerTeamID" : "PZYM8XX95Q", | ||
| "_lastSynchronizedDate" : 689685986.85126996 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having second thoughts about this. I added the StoreKit configuration with sync enabled, but if we're only going to use this for testing, maybe I should convert to local and ensure it only has the debug product? I'm not sure we want the whole product catalog synced to a public repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, if it's only for unit testing I would convert it to local and only add the debug product, no need to have the whole product catalog even if I don't see huge security issues with that.
You can test the changes from this Pull Request by:
|
| "_applicationInternalID" : "1389130815", | ||
| "_developerTeamID" : "PZYM8XX95Q", | ||
| "_lastSynchronizedDate" : 689685986.85126996 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, if it's only for unit testing I would convert it to local and only add the debug product, no need to have the whole product catalog even if I don't see huge security issues with that.
|
Great job! ILGTM, now we have vital parts tested 👍
That's a good point. It seems to me like MockNetwork is easy to extend to validate that an endpoint was called; do you think it is worth doing that (In other PR/issue)? I see value in that, not only for this task, but for other cases when we want to test that an endpoint was called. |
|
👍🏽 I'll take a look at extending MockNetwork in a separate PR |
Closes: #8057
Description
This adds some unit tests for the InAppPurchaseStore. I haven't tested every single aspect since it seems like
MockNetworkcan only simulate responses and not validate that an endpoint was called. So I'm not sure how to test the transaction listener, but I feel like this tests already touch the most critical points and it's an improvement over no tests 🤷🏽Note that I had to bring back the local StoreKit configuration file for this to work. After testing different variations, I realized that there's no need to set the Xcode scheme to use it. As long as the file is included in the test bundle, when you initialize the
SKTestSession, it will switch to the local configuration. The only tricky aspect was that I had to add the tests in the WooCommerce project, since Yosemite tests run without a host application and it doesn't seem likeStoreKitTestworks that way.Testing instructions
Unit tests should pass
RELEASE-NOTES.txtif necessary.