You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When working on #404 , I discovered that the PaymentHandler test suite is unfortunately quite far diverged from both spec and implementation currently (and the implementation is somewhat diverged from the spec too).
A short list of problems I found in my initial pass of the test suite (but there may be others!):
Tests treat supportedMethods as a list still, not a string
Tests assert that additionalDisplayItems and total are not in modifiers for "canmakepaymentevent", which they are in Chrome's implementation
Tests assert that modifier.data exists for "canmakepaymentevent", and it doesn't seem to for Chrome
Tests presume that "canmakepaymentevent" affects canMakePayment(), not hasEnrolledInstrument()
Tests presume that if "canmakepaymentevent" returns false, then show() will throw a NotSupportedError
Tests try to reject the "canmakepaymentevent" respondWith with Error objects that have actual messages, which is not supported afaik (maybe they silently become false?)
Some of these may be actual bugs in Chrome, whilst some reflect how both the PaymentHandler spec and test suite have diverged from changes in both PaymentRequest spec and in the reality of the Chrome implementation. In all worlds, the test suite (and spec) desperately needs some TLC to at least reflect the shipping reality!
The text was updated successfully, but these errors were encountered:
When working on #404 , I discovered that the PaymentHandler test suite is unfortunately quite far diverged from both spec and implementation currently (and the implementation is somewhat diverged from the spec too).
A short list of problems I found in my initial pass of the test suite (but there may be others!):
supportedMethods
as a list still, not a stringadditionalDisplayItems
andtotal
are not in modifiers for "canmakepaymentevent", which they are in Chrome's implementationmodifier.data
exists for "canmakepaymentevent", and it doesn't seem to for ChromerespondWith
with Error objects that have actual messages, which is not supported afaik (maybe they silently become false?)Some of these may be actual bugs in Chrome, whilst some reflect how both the PaymentHandler spec and test suite have diverged from changes in both PaymentRequest spec and in the reality of the Chrome implementation. In all worlds, the test suite (and spec) desperately needs some TLC to at least reflect the shipping reality!
The text was updated successfully, but these errors were encountered: