Skip to content

Latest commit

 

History

History
204 lines (115 loc) · 5.52 KB

NtarhInitPagesRouter.md

File metadata and controls

204 lines (115 loc) · 5.52 KB

next-test-api-route-handlerDocs


next-test-api-route-handler / NtarhInitPagesRouter

Interface: NtarhInitPagesRouter<NextResponseJsonType>

The parameters expected by testApiHandler when using pagesHandler.

Extends

Type Parameters

NextResponseJsonType = unknown

Properties

appHandler?

optional appHandler: undefined

Defined in

index.ts:243


pagesHandler

pagesHandler: NextApiHandler<any> | object

The actual Pages Router route handler under test. It should be an async function that accepts NextApiRequest and NextApiResult objects (in that order) as its two parameters.

Note that type checking for res.send and similar methods was retired in NTARH@4. Only the response.json method returned by NTARH's fetch wrapper will have a typed result.

Defined in

index.ts:242


params?

optional params: Record<string, unknown>

params is passed directly to the handler and represents processed dynamic routes. This should not be confused with query string parsing, which is handled automatically.

params: { id: 'some-id' } is shorthand for paramsPatcher: (params) => { params.id = 'some-id' }. This is useful for quickly setting many params at once.

Defined in

index.ts:253


paramsPatcher()?

optional paramsPatcher: (params) => Promisable<void | Record<string, unknown>>

A function that receives params, an object representing "processed" dynamic route parameters. Modifications to params are passed directly to the handler. You can also return a custom object from this function which will replace params entirely.

Parameter patching should not be confused with query string parsing, which is handled automatically.

Parameters

params: Record<string, unknown>

Returns

Promisable<void | Record<string, unknown>>

Defined in

index.ts:263


rejectOnHandlerError?

optional rejectOnHandlerError: boolean

If false, errors thrown from within a handler are kicked up to Next.js's resolver to deal with, which is what would happen in production. If true, the testApiHandler function will reject immediately instead.

You should use rejectOnHandlerError whenever you want to manually handle an error that bubbles up from your handler (which is especially true if you're using expect within your handler) or when you notice a false negative despite exceptions being thrown.

Default

false

Inherited from

NtarhInit.rejectOnHandlerError

Defined in

index.ts:137


requestPatcher()?

optional requestPatcher: (request) => Promisable<void>

A function that receives an IncomingMessage object. Use this function to edit the request before it's injected into the handler.

Note: all replacement IncomingMessage.header names must be lowercase.

Parameters

request: IncomingMessage

Returns

Promisable<void>

Defined in

index.ts:274


responsePatcher()?

optional responsePatcher: (res) => Promisable<void>

A function that receives a ServerResponse object. Use this function to edit the response before it's injected into the handler.

Parameters

res: ServerResponse<IncomingMessage>

Returns

Promisable<void>

Defined in

index.ts:279


test()

test: (parameters) => Promisable<void>

test is a function that runs your test assertions. This function receives one destructured parameter: fetch, which is equivalent to globalThis.fetch but with the first parameter omitted.

Parameters

parameters

parameters.fetch

Returns

Promisable<void>

Inherited from

NtarhInit.test

Defined in

index.ts:143


url?

optional url: string

url: 'your-url' is shorthand for requestPatcher: (req) => { req.url = 'your-url' }

Defined in

index.ts:284