Generate unit tests
A suite can reach 90% line coverage and still never try an empty list: send your function and its framework, such as Jest or PyTest, and get a runnable test file with normal, boundary, empty and error cases. You pay per use, with no subscription.
Run it online
Run this on our servers with your account. Free tools run in your browser; this one bills your KIT balance per the price above.
The tests that catch real bugs are almost never the happy-path ones you thought to write first; they're the empty array, the null field, the negative number nobody expected to reach that function.
Why coverage alone misses the bugs that matter
It is entirely possible to reach 90% line coverage while never testing what happens when a list is empty, a string is unexpectedly long, or two inputs that are valid on their own combine into an invalid state. Coverage measures which lines ran, not which failure modes were considered, and that gap is where most regressions slip through. The cases that catch real bugs are rarely the happy path you thought of first. So the generated file is organized into clearly named groups: normal inputs, boundary values, empty or missing inputs, and the error conditions the function's own logic implies, such as a division that could hit zero or a lookup that could miss.
How to use the draft safely
The tests assert on how the function behaves today, so if it has a bug, a naive case can lock that bug in as correct. Treat the output as a strong first draft: read each assertion, confirm it matches the behavior you intend rather than the behavior you have, and trim the cases that do not matter for your codebase before merging. Typical uses are backfilling a module nobody tested, such as a payment calculation with rounding and zero amounts, sketching tests before writing a new function, and building a safety net before a refactor. You choose the language and the framework, for example Jest, PyTest, PHPUnit or JUnit, and the file follows its conventions.
The gap between coverage and confidence
It's entirely possible to hit 90% line coverage while never testing what happens when a list is empty, a string is unexpectedly long, or two inputs that are individually valid combine into an invalid state. Coverage percentage measures which lines ran, not which failure modes were considered, and that distinction is exactly where most regressions slip through.
What you send and what you get
You submit a function, class or module along with its language and the testing framework you use, such as Jest, PyTest, PHPUnit or JUnit. The response is a runnable test file written in that framework's syntax and conventions, organized into clearly named test cases: normal inputs, boundary values, empty or null inputs, and any error conditions the function's own logic implies, like a division that could hit zero or a lookup that could miss.
How it fits real workflows
The common pattern is generating a starting test file for a function that has none, then a developer reviews and trims it, since not every suggested case will matter for every codebase. It also fits well right after a bug fix: submit the function post-fix and ask specifically for a regression case that would have caught the bug that just shipped, so it can't silently come back.
What you should still review
Generated tests assert on the function's actual current behavior, so if the function has a bug, a naive test could encode that bug as "correct." Treat the output as a strong first draft: read the assertions, confirm they match intended behavior rather than just current behavior, and adjust before merging.
What you can do with it
Backfilling tests on an untested module
A team inherits a payment-calculation function with no tests and generates a full suite covering rounding, currency edge cases and zero-amount inputs before refactoring it.
TDD scaffolding for a new function
A developer sketches a function signature and generates tests first to clarify expected behavior for boundary inputs before writing the implementation.
Pre-refactor safety net
Before restructuring a complex validation function, a team generates a broad test suite to lock in current behavior and catch accidental changes during the refactor.
FAQ
Which testing frameworks are supported?
Common frameworks including Jest, PyTest, PHPUnit and JUnit are supported; specify the one your project uses and the output matches its syntax and conventions.
Does it only generate happy-path tests?
No, it's specifically tuned to include boundary values, empty and null inputs, and error conditions implied by the function's own logic, not just the obvious success case.
Can generated tests encode an existing bug as correct?
Yes, that's a real risk with any test generated from current behavior, so review assertions against intended behavior before merging, especially for logic you suspect is already buggy.
Is there a free trial?
There's no free tier — free tiers get abused and slow everyone down. No subscription, no tokens, no invented credits, and a failed task is never charged.
What happens if generation fails?
It retries automatically up to three times; a persistent failure returns a clear error and is never charged.
When is the best moment to generate tests?
Three moments work well: for a function that has no tests yet, before refactoring something complex so accidental changes show up, and right after a bug fix, asking for a case that would have caught the bug so it cannot quietly come back.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/dev/unit-tests \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}'const res = await fetch("https://api.kit.forhosting.com/dev/unit-tests", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/unit-tests",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/unit-tests", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"El informe trimestral cerró con 1,2 M€ de ingresos."}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/unit-tests", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "El informe trimestral cerró con 1,2 M€ de ingresos."
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.unit_tests",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
422 | task_failed | The task failed after 3 retries. You are never charged for it. |
Technical notes
This endpoint reads a function or module and returns a test suite that covers the obvious cases and the ones you'd only find after a production incident.
The gap between coverage and confidence
This endpoint is built to close that specific gap rather than to maximize a coverage number.
Why edge cases specifically
Boundary and edge-case testing is one of the oldest disciplines in software quality for a reason: bugs cluster at boundaries, off-by-one errors, type coercion surprises, and the seams between two pieces of validated-elsewhere logic. A test generator that only mirrors the function's happy path back at you adds files to your repo without adding protection, so this endpoint is specifically tuned to reason about what could go wrong with each parameter, not just what the function does when everything goes right.
Integration use cases
Regression test after a bug fix
After fixing a date-parsing bug, a developer generates a targeted test case for exactly the input that broke, so it can never silently regress.
Technical questions
How much does it cost?
$0.003 per request plus $0.0135 per 1000 words of source submitted, and you're only billed for tasks that complete successfully.
Can I generate a single regression test for a specific bug?
Yes, submit the fixed function and describe the input that previously broke it to get a targeted regression case rather than a full suite.
Is my code retained after the request?
No. Submitted source and generated tests are deleted after the retention period and are never used to train models.