← Cloudflare Workers / workers / testing / vitest-integration
Конфигурация
Интеграция Workers Vitest предоставляет дополнительную конфигурацию поверх обычных опций Vitest с помощью cloudflareTest() плагин Vite.
Пример конфигурации:
import { cloudflareTest } from "@cloudflare/vitest-plugin";
import { defineConfig } from "vitest/config";
export default defineConfig({
plugins: [
cloudflareTest({
wrangler: {
configPath: "./wrangler.jsonc",
},
}),
],
});API
Следующие API экспортируются из @cloudflare/vitest-plugin пакет.
cloudflareTest(options)
Плагин Vite, который настраивает Vitest на использование интеграции с Workers с корректными настройками разрешения модулей, а также обеспечивает проверку типов для CloudflareTestOptions. Добавьте это в plugins массив в конфигурации Vitest рядом с defineConfig() ↗ из Vitest.
Также принимает необязательно-async функция, возвращающая options.
import { cloudflareTest } from "@cloudflare/vitest-plugin";
import { defineConfig } from "vitest/config";
export default defineConfig({
plugins: [
cloudflareTest({
// Refer to CloudflareTestOptions...
}),
],
});buildPagesASSETSBinding(assetsPath)
Экспортировано из @cloudflare/vitest-plugin/config. Создаёт привязку Pages ASSETS, которая отдаёт файлы из assetsPath. Это необходимо, если вы используете createPagesEventContext() для тестирования Pages Functions. См. Рецепт для Pages для исчерпывающего примера.
import path from "node:path";
import { buildPagesASSETSBinding, cloudflareTest } from "@cloudflare/vitest-plugin";
import { defineConfig } from "vitest/config";
export default defineConfig({
plugins: [
cloudflareTest(async () => {
const assetsPath = path.join(__dirname, "public");
return {
miniflare: {
serviceBindings: {
ASSETS: await buildPagesASSETSBinding(assetsPath),
},
},
};
}),
],
});readD1Migrations(migrationsPath)
Экспортировано из @cloudflare/vitest-plugin/config. Считывает все Миграции D1 хранится в migrationsPath и возвращает их, упорядоченными по номеру миграции. Содержимое каждой миграции разбивается на массив отдельных SQL-запросов. Вызовите applyD1Migrations() функцию внутри теста или файл настройки ↗ чтобы применить миграции. См. Рецепт D1 ↗ пример проекта с использованием миграций.
import path from "node:path";
import { cloudflareTest, readD1Migrations } from "@cloudflare/vitest-plugin";
import { defineConfig } from "vitest/config";
export default defineConfig({
plugins: [
cloudflareTest(async () => {
const migrationsPath = path.join(__dirname, "migrations");
const migrations = await readD1Migrations(migrationsPath);
return {
miniflare: {
// Add a test-only binding for migrations, so we can apply them in a setup file
bindings: { TEST_MIGRATIONS: migrations },
},
};
}),
],
test: {
setupFiles: ["./test/apply-migrations.ts"],
},
});CloudflareTestOptions
Параметры, передаваемые напрямую в cloudflareTest().
-
main: строка, необязательно- Точка входа Worker, запускаемая в том же изоляте/контексте, что и тесты. Этот параметр требуется для использования Durable Objects без явного
scriptNameесли классы определены в одном и том же Worker. Этот файл проходит через трансформации Vite и может быть на TypeScript. Обратите внимание, чтоimport module from "<path-to-main>"внутри тестов даёт точно такой жеmoduleэкземпляр, так как он используется внутри дляexportsи привязки Durable Object. Еслиwrangler.configPathзадан, а эта опция нет, значение будет прочитано изmainполе в этом файле конфигурации.
- Точка входа Worker, запускаемая в том же изоляте/контексте, что и тесты. Этот параметр требуется для использования Durable Objects без явного
-
miniflare:SourcelessWorkerOptions & { workers?: WorkerOptions\[]; }необязательный-
Используйте это, чтобы указать конфигурационные данные, которые обычно хранятся в конфигурационный файл Wrangler, например привязки, даты совместимости, а также флаги совместимости.
WorkerOptionsинтерфейс определён здесь ↗. Используйтеmainпараметр выше, чтобы настроить точку входа, вместо Miniflarescript,scriptPath, илиmodulesопции.- Если нет
compatibility_dateуказан, тест будет использовать последнюю локально доступную дату.
- Если нет
-
Если в проекте используется несколько Workers, вы можете настроить вспомогательные Workers, которые выполняются в одном
workerdпроцессе, что и ваши тесты, и к ним можно привязываться. Вспомогательные Workers настраиваются с помощьюworkersмассив, содержащий обычные MiniflareWorkerOptions↗ объекты. Обратите внимание, что в отличие отmainWorker, вспомогательные Workers:- Не может иметь точки входа на TypeScript. Сначала скомпилируйте вспомогательные Workers в JavaScript. Для этого можно использовать
wrangler deploy --dry-run --outdir distкоманду для этого. - Используйте стандартную семантику разрешения модулей Workers. См. Изоляция и параллелизм странице для получения дополнительной информации.
- Не может обращаться к
cloudflare:testмодуль. - Не требуйте конкретных дат совместимости или флагов.
- Можно записать с помощью Синтаксис Service Worker.
- Не затрагиваются глобальными моками, определёнными в ваших тестах.
- Не может иметь точки входа на TypeScript. Сначала скомпилируйте вспомогательные Workers в JavaScript. Для этого можно использовать
-
-
wrangler:{ configPath?: string; environment?: string; }необязательный-
Путь к конфигурационный файл Wrangler чтобы загрузить
main, настройки совместимости и привязки . Эти параметры будут объединены сminiflareпараметр выше, сminiflareзначения имеют приоритет. Например, если в вашей конфигурации Wrangler определена привязка к сервису с именемSERVICEк Worker с именемservice, но вы включилиserviceBindings: { SERVICE(request) { return new Response("body"); } }вminiflareпараметр, все запросы кSERVICEв тестах возвращал быbody. Обратите внимание наconfigPathпринимает как.tomlи.jsonфайлы. -
С помощью параметра environment можно указать Окружение Wrangler для получения привязок и переменных.
-
Динамическая конфигурация с помощью inject
Можно передать async функцию, чтобы cloudflareTest() который получает inject функция. Это позволяет определить miniflare конфигурацию на основе значений, переданных из globalSetup ↗ scripts. Используйте это, если в конфигурации есть значение, которое генерируется динамически и становится известно только во время выполнения тестов. Например, глобальный скрипт настройки может запускать вышестоящий сервер на случайном порту. Этот порт можно provide()d, а затем inject(), то есть внедрён в конфигурацию для привязки к внешней службе или Hyperdrive. См. Рецепт Hyperdrive ↗ пример проекта, использующего подход provide/inject.
Наглядный пример
// env.d.ts
declare module "vitest" {
interface ProvidedContext {
port: number;
}
}
// global-setup.ts
import type { GlobalSetupContext } from "vitest/node";
export default function ({ provide }: GlobalSetupContext) {
// Runs inside Node.js, could start server here...
provide("port", 1337);
return () => {
/* ...then teardown here */
};
}
// vitest.config.ts
import { cloudflareTest } from "@cloudflare/vitest-plugin";
import { defineConfig } from "vitest/config";
export default defineConfig({
plugins: [
cloudflareTest(({ inject }) => ({
miniflare: {
hyperdrives: {
DATABASE: `postgres://user:[email protected]:${inject("port")}/db`,
},
},
})),
],
test: {
globalSetup: ["./global-setup.ts"],
},
});SourcelessWorkerOptions
Без исходного кода WorkerOptions тип без script, scriptPath, или modules свойства. См. раздел Miniflare WorkerOptions ↗ тип для получения дополнительных сведений.
type SourcelessWorkerOptions = Omit<
WorkerOptions,
"script" | "scriptPath" | "modules" | "modulesRoot"
>;