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
Add validation to catch blank ephemeral keys in CustomerConfiguration #2517
base: master
Are you sure you want to change the base?
Conversation
2bd7d0d
to
debae23
Compare
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.
LG2M, @eurias-stripe can you review the Tuist changes?
StripePaymentSheet/StripePaymentSheet/Source/PaymentSheet/PaymentSheetConfiguration.swift
Outdated
Show resolved
Hide resolved
func test_customerConfigurationInit_assertsWhenEphemeralKeyIsBlank() throws { | ||
let exception = catchBadInstruction { | ||
_ = PaymentSheet.CustomerConfiguration(id: "foo", ephemeralKeySecret: "") | ||
} | ||
|
||
XCTAssertNotNil(exception) |
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.
🤩
93dabc2
to
8fd3dac
Compare
CwlPreconditionTesting allows us to unit test traps (i.e. fatalError, assert, precondition). We currently don't have any way to test these in the repo, so engineers simply don't test our assertions. This will improve the overall state of our unit tests by encouraging testing of more code paths. Further reading on how CwlPreconditionTesting works: https://www.cocoawithlove.com/blog/2016/02/02/partial-functions-part-two-catching-precondition-failures.html
We currently don't validate that an ephemeral key is non-empty when a user includes it in the `CustomerConfiguration`. This ends up giving users a pretty obscure error in the API response, and is difficult to debug today. Including this validation will catch this issue early and provide users a better debugging experience.
Co-authored-by: Yuki <[email protected]>
b36b25f
to
6a71a2e
Compare
@yuki-stripe Had to fix a couple tests that I broke. Could you PTAL and make sure I'm not breaking the expected behavior for those tests? |
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.
Finally a way to test assertions!
CHANGELOG.md
Outdated
@@ -2,6 +2,9 @@ | |||
### Payments | |||
* [Fixed] STPPaymentHandler.handleNextAction allows payment methods that are delayed or require further customer action like like SEPA Debit or OXXO. | |||
|
|||
### PaymentSheet | |||
* [Added] Improved validation for ephemeral keys |
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.
Does this need a changelog entry? This is not a user facing change.
In case we do need the entry, tiny nit:
* [Added] Improved validation for ephemeral keys | |
* [Added] Improved validation for ephemeral keys. |
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 not sure what we normally do/do not include in the changelog. It does improve user-facing error messages that users have complained about in the past, so sorta-kinda user facing?
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 can go either way with this one. If users have specifically mentioned this then it is worth calling it out.
e9c42e0
Co-authored-by: eurias-stripe <[email protected]>
Summary
Added an assertion to catch blank ephemeral keys when a user instantiates a
CustomerConfiguration
Motivation
We currently don't validate that an ephemeral key is non-empty when a
user includes it in the
CustomerConfiguration
. This ends up givingusers a pretty obscure error in the API response, and is difficult to
debug today.
Including this validation will catch this issue early and provide users
a better debugging experience.
As part of this change, I also added a dependency on CwlPreconditionTesting.
CwlPreconditionTesting allows us to unit test traps (i.e. fatalError,
assert, precondition). We currently don't have any way to test these in
the repo, so engineers simply don't test our assertions. This will
improve the overall state of our unit tests by encouraging testing of
more code paths.
Testing
Changelog