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!
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!):
supportedMethodsas a list still, not a stringadditionalDisplayItemsandtotalare not in modifiers for "canmakepaymentevent", which they are in Chrome's implementationmodifier.dataexists for "canmakepaymentevent", and it doesn't seem to for ChromerespondWithwith 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!