Convert Your Existing APIs to Glubean Tests

You do not need to rewrite everything by hand.

Most teams convert 80-90% of their existing API collections with AI assistance. Manual effort goes only into flow design and edge cases.

If your first reaction after the demo is:

“We have hundreds of Postman requests. Are we supposed to rewrite all of this one by one?”

The short answer is: no.

npx @glubean/cli init

What this migration is really about

Migration is not a text-format conversion problem. It is a test architecture problem:

• Keep request definitions you already have.
• Let AI generate Glubean test code from those sources.
• Make a few structural decisions once (auth, grouping, assertion depth).
• Reuse that pattern across the rest of the collection.

Once the pattern is locked, conversion speed increases dramatically.

Supported source formats

The table above lists common formats, but there’s no strict requirement. If you have a README with endpoint descriptions, a Confluence page, a JSON request/response sample, or even a Slack thread listing your endpoints — drop it into the project and point the AI at it. As long as the document describes URLs, methods, headers, or payloads, AI can generate tests from it.

What converts well automatically

AI assistants can reliably convert:

• HTTP methods and URLs → ctx.http.get/post/put/patch/delete(...)
• Query parameters → searchParams
• Request headers and JSON bodies
• Basic status assertions → ctx.expect(res.status).toBe(...)
• Environment placeholders → ctx.vars.require(...)
• Sensitive values → ctx.secrets.require(...)
• OpenAPI operationId → test IDs
• OpenAPI tags → test grouping (typically one file per tag/folder)

What still needs your decisions

AI cannot infer business intent from export files alone. You still need to decide:

1. Granularity — independent tests vs multi-step flow tests
2. Auth model — static token vs dynamic login setup
3. Secrets boundary — which values must be ctx.secrets
4. Assertion depth — status-only vs key fields vs schema validation
5. File layout — one file per resource/tag vs merged files

These five choices determine 80% of migration quality.

Stop. Do not guess. List what you're unsure about and ask me before continuing.

Model selection matters (a lot)

Use different model tiers at different migration stages:

Practical strategy:

1. Start with a stronger model for architecture decisions.
2. Freeze your conventions (configure.ts, naming, auth helper, assertions).
3. Switch to a faster model for batch conversion.
4. Use a stronger model again for final review.

This gives you both quality and speed.

Recommended migration path

You are in a Glubean project (Node + @glubean/sdk).
Before generating any files, do a feasibility scan only.

Please:
1) Read project context first:
   - package.json
   - tests/ and explore/ structure
   - existing configure.ts (if any)
   - @glubean/sdk usage patterns in this repo
2) Read source API assets:
   - [Postman/OpenAPI/REST files path]
3) Output a feasibility report (no code generation yet):
   - What can be converted automatically
   - What requires manual decisions
   - Risks / unknowns / blockers
   - Proposed file plan (which .test.ts files to create)
   - Proposed auth strategy and assertion depth
   - A small sample (one endpoint/flow) plan only
4) If anything is ambiguous (auth model, secret classification,
   pre-request script logic), list it as an open question —
   do NOT guess and continue.
5) Wait for my approval before writing any files.

Approved. Now generate files according to the plan.
Start with one representative flow first, then stop for review.

npm test
# or
glubean run tests/

Mapping guide

Prompt templates by source format

Use the feasibility scan (step 1 above) first, then follow up with one of these:

I have a Postman Collection at [path].
Please convert it into Glubean tests using @glubean/sdk.

Requirements:
- Group by Postman folder, one file per folder under tests/
- Use ctx.vars.require("BASE_URL") for base URL
- Sensitive keys [API_KEY, PASSWORD, TOKEN] must use ctx.secrets.require(...)
- Use builder flow (.setup/.step/.teardown) for stateful sequences
- Use single test(...) for isolated endpoints
- Assertions: status + key fields present
- Create a shared tests/configure.ts with configure({ vars, secrets, http })
- If any script logic is not safely convertible, add a TODO comment

Return:
1) tests/configure.ts
2) generated test files
3) a short "manual follow-up" list

I have an OpenAPI 3 spec at [path].
Generate Glubean tests for non-deprecated endpoints.

Requirements:
- Group by OpenAPI tag, one file per tag
- Use operationId as test id where available
- Use ctx.vars for non-sensitive values and ctx.secrets for sensitive values
- Add status assertions based on responses
- Where schemas are available, add schema validation logic
- Create tests/configure.ts with shared HTTP settings
- Mark uncertain conversions with TODO comments

I have a REST Client file at [path].
Convert each ### block into one Glubean test export.

Requirements:
- Map {{BASE_URL}} to ctx.vars.require("BASE_URL")
- Map sensitive placeholders (TOKEN, API_KEY, PASSWORD) to ctx.secrets.require(...)
- Add status assertions using the expected status from context/comments.
  If unknown, keep a TODO instead of guessing.
- Put output in tests/[name].test.ts

configure.ts baseline

import { configure } from "@glubean/sdk";
 
export const { vars, secrets, http } = configure({
  vars: { baseUrl: "BASE_URL" },
  secrets: { apiToken: "API_TOKEN" },
  http: {
    prefixUrl: "BASE_URL",
    headers: { Authorization: "Bearer {{API_TOKEN}}" },
  },
});

Then import and use in any test file:

import { test } from "@glubean/sdk";
import { http } from "./configure.ts";
 
export const listUsers = test("list-users", async (ctx) => {
  const data = await http.get("users").json();
  ctx.expect(data.length).toBeGreaterThan(0);
});

Quality checklist

• ctx.vars.require(...) is used for non-sensitive runtime config
• ctx.secrets.require(...) is used for tokens, keys, passwords
• Stateful flows use builder (.setup() → .step() → .teardown())
• Data-creating tests include cleanup paths
• Assertions are not status-only for critical endpoints
• Any unconverted dynamic script logic is explicitly marked with TODO

Known limits

These often require manual touch-ups:

• Complex Postman pre-request scripts (custom signing/encryption)
• Dynamic test scripts with branching business logic
• Implicit state dependencies across folders/collections
• APIs with undocumented response variance

That is normal. Migration succeeds when 80-90% is automated and the remaining 10-20% is clear and reviewable.

What’s next?

Ready to start? Set up your project first, then come back here with your export file.

• Quick Start — install the extension and run npx @glubean/cli init
• AI Integration — tips for better AI-generated tests
• Workflow: Explore vs Tests — start in explore/, promote to tests/