new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Hono · all subjects

helpers/testing

7 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

testClient() import

The testClient() function is imported from 'hono/testing'.

testClient() returns typed client

The testClient() function takes a Hono app instance as its first argument and returns an object typed according to the app's routes, similar to the Hono Client. This allows type-safe calling of routes with editor autocompletion in tests.

testClient() type inference requirement

For testClient() to correctly infer route types and provide autocompletion, routes must be defined using chained methods directly on the Hono instance. The type inference relies on the type flowing through chained .get(), .post(), etc. calls. If routes are defined separately after creating the Hono instance, testClient() will not have the necessary type information for specific routes.

testClient() basic usage example

import { Hono } from 'hono' import { testClient } from 'hono/testing' import { describe, it, expect } from 'vitest' import app from './app' describe('Search Endpoint', () => { const client = testClient(app) it('should return search results', async () => { const res = await client.search.$get({ query: { q: 'hono' }, }) expect(res.status).toBe(200) expect(await res.json()).toEqual({ query: 'hono', results: ['result1', 'result2'], }) }) }) This example shows basic testClient usage with query parameters and response assertions.

testClient() with headers and init options

import { Hono } from 'hono' import { testClient } from 'hono/testing' import { describe, it, expect } from 'vitest' import app from './app' describe('Search Endpoint', () => { const client = testClient(app) it('should return search results', async () => { const token = 'thi••••••en' const res = await client.search.$get( { query: { q: 'hono' }, }, { headers: { Authorization: `Bearer ${token}`, 'Content-Type': `application/json`, }, } ) expect(res.status).toBe(200) expect(await res.json()).toEqual({ query: 'hono', results: ['result1', 'result2'], }) }) }) This example shows passing headers and init options as the second parameter to a testClient route call.

testClient() second parameter structure

The second parameter to a testClient route call can include headers and an init property as a RequestInit object, allowing you to set headers, method, body, and other request options.

testClient() chained route definition example

const app = new Hono().get('/search', (c) => { const query = c.req.query('q') return c.json({ query: query, results: ['result1', 'result2'] }) }) export default app This demonstrates the required pattern of chaining route definitions directly on the Hono instance constructor for testClient() type inference to work.

Give your agent this brain