Skip to content
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

663/mk/standardize op client requests #971

Merged
merged 10 commits into from
Jan 13, 2023

Conversation

mkurapov
Copy link
Contributor

@mkurapov mkurapov commented Jan 12, 2023

Changes proposed in this pull request

  • Update incoming payment & outgoing payment client list create complete requests to use paymentPointer as an argument instead of url, e.g.:
await client.incomingPayment.create({ url, accessToken, body: { description, incomingAmount } } // before
await client.incomingPayment.create({ paymentPointer, accessToken }, { description, incomingAmount }) // after
  • Update tests to get 100% coverage:
    Screen Shot 2023-01-13 at 1 57 29 PM

Context

Checklist

  • Related issues linked using fixes #number
  • Tests added/updated
  • Documentation added
  • Make sure that all checks pass

@github-actions github-actions bot added pkg: open-payments type: source Changes business logic type: tests Testing related labels Jan 12, 2023
const openApiValidators = mockOpenApiResponseValidators()

describe('createOutgoingPaymentRoutes', (): void => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not needed, since routes describe block takes care of this

Comment on lines +39 to +42
jest
.spyOn(openApi, 'createResponseValidator')
// eslint-disable-next-line @typescript-eslint/no-explicit-any
.mockImplementation(mockResponseValidator as any)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we check that the spy is called?

Copy link
Contributor Author

@mkurapov mkurapov Jan 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's already testing this (albeit indirectly): if the createResponseValidator doesn't get the proper path and method when its called, the test will fail based on the expectation of true on L57

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, the true! 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not the easiest to see when first reading it, but that was the best solution I could come up with to test the correct validator was passed in

Comment on lines 12 to 17
interface RequestWithUrlArgs {
url: string
accessToken: string
}

interface PostArgs<T = undefined> {
url: string
body?: T
accessToken: string
}

interface ListGetArgs {
interface RequestWithPaymentPointerArgs {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of (Sub)ResourceRequestArgs and CollectionRequestArgs?

That might also somewhat future-proof this for

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, I like that better

packages/open-payments/src/client/incoming-payment.test.ts Outdated Show resolved Hide resolved
packages/open-payments/src/client/incoming-payment.test.ts Outdated Show resolved Hide resolved
packages/open-payments/src/test/helpers.ts Outdated Show resolved Hide resolved
packages/open-payments/src/test/helpers.ts Outdated Show resolved Hide resolved
@@ -41,6 +41,20 @@ export interface RouteDeps extends BaseDeps {
logger: Logger
}

export interface UnauthenticatedResourceRequestArgs {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's a bit wordy given what this contains, but I like how the types read in the grant.ts, where the first method (to create a grant) has UnauthenticatedResourceRequestArgs, while all the other ones are ResourceRequestArgs with the explicit accessToken

wilsonianb
wilsonianb previously approved these changes Jan 13, 2023
Comment on lines 48 to 56
export interface ResourceRequestArgs {
url: string
accessToken: string
}

export interface CollectionRequestArgs {
paymentPointer: string
accessToken: string
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
export interface ResourceRequestArgs {
url: string
accessToken: string
}
export interface CollectionRequestArgs {
paymentPointer: string
accessToken: string
}
interface AuthenticatedRequestArgs {
accessToken: string
}
export interface ResourceRequestArgs
extends UnauthenticatedResourceRequestArgs,
AuthenticatedRequestArgs {}
export interface CollectionRequestArgs extends AuthenticatedRequestArgs {
paymentPointer: string
}

Comment on lines 41 to 43
for (const key in override) {
process.env[key] = override[key]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for (const key in override) {
process.env[key] = override[key]
}
Object.assign(process.env, override)

wilsonianb
wilsonianb previously approved these changes Jan 13, 2023
# Conflicts:
#	packages/open-payments/src/client/quote.ts
#	packages/open-payments/src/test/helpers.ts
@@ -35,29 +35,6 @@ describe('quote', (): void => {
const paymentPointer = 'http://localhost:1000/.well-known/pay'
const accessToken = 'accessToken'

describe('createQuoteRoutes', (): void => {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

already tested via routes describe block lower in the file

@mkurapov mkurapov merged commit b3ce7af into main Jan 13, 2023
@mkurapov mkurapov deleted the 663/mk/standardize-op-client-requests branch January 13, 2023 23:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: source Changes business logic type: tests Testing related
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants