Continuous testing for every background job you run.
Kerno triggers each task through your own broker, the way your app does, and verifies what it changed.
Kerno triggers async work the way your app does, then verifies what it changed.
Consumer discovery
Celery tasks, Graphile Worker jobs and scheduled work each become their own subject, with their own scenarios.
Dispatch through your broker
Kerno publishes to Redis, RabbitMQ or your own Postgres job queue, the same path your application uses.
Unresolved wiring reporting
A dynamic task name or a queue resolved at deploy time is reported with the reason, and never guessed.
Store and message assertions
Kerno reads the rows a job wrote and subscribes to what it published, then checks both against the run.
Per-run data isolation
Each scenario arranges its own rows and its own correlation id, so a scheduler firing mid-run cannot skew it.
Job behavior drift
The assertions from the last run are the baseline, so a changed outcome or payload shows up as a diff.
Catches failed jobs, missing writes and payload drift across every worker.
Task execution
Terminal state, task outcome, and the work a job actually did.
Queue messages
Consumer handling, message payloads, and chained task dispatch.
Scheduled jobs
Beat entries, cron registrations, and the task behind each one.
Store writes
Rows created, updated and removed, checked against your own schema.
Published messages
Payloads a job emits, the queues it lands on, and their shape.
Idempotency
A repeat dispatch, and whether the same effect lands twice.
- Python
- TypeScript
- JavaScript
- Redis
- RabbitMQ
- AWS
- Azure
- PostgreSQL
- MongoDB
Kerno applies your rules and standards to every job it plans and tests.
Reads your rules and standards in plain English
Write a rule the way you would explain it to a new engineer, and scope it to the repositories and paths it applies to.
Works from the context your team already wrote
Agent instruction files, service READMEs and the docs in your repository shape how every job gets tested.
Gets more accurate with every run you review
Kerno learns from each run and the feedback you give it, and carries what it learns into the tests that follow.
FAQs
Got any extra questions? Reach out on our community channel and we'll be happy to help.
How does Kerno test a Celery task?
Kerno discovers the task, triggers it by publishing to the broker the way your app does, and verifies the rows it wrote and the messages it published.
Does Kerno test queue consumers?
Yes. Kerno discovers queue consumers and tests how they handle messages, including the rows and messages they produce.
Can Kerno test scheduled or cron jobs?
Yes. Kerno reads your beat entries and cron registrations, then tests the task behind each one by dispatching it the way the scheduler would.
How does Kerno trigger a background job?
By publishing to the broker, the same path your application uses, so the job runs the way it does in production.
Which task frameworks does Kerno support?
Celery on Python and Graphile Worker on TypeScript and JavaScript, each triggered through your own broker. SQS handlers declared in a serverless manifest are discovered with their queue and arguments.
Does async testing run in CI?
Yes. Committed scenarios replay in CI on every change.