Add and run tests

Save read-only tests of your keys, run them whenever you like and see what changed since a test last passed.

In short

A check asks one read-only question - does a key exist or is it gone, does it hold this value, type, length, hash field or JSON value, does it expire in time, how many keys match a pattern, are the server's memory and hit rate inside their limits, and does the cache say the same as your database. Save tests on a connection and run them whenever you like; a failed test shows what changed since it last passed.

Before you start

Who: adding, editing and deleting tests needs "Manage cache connections"; running them needs only access to the connection.
Plan: a connection holds at most 50 tests. Tests only read, so they are safe on Production.
First: a connection, and the key you want to watch.

Add a test and run tests

Pick the connection, open the "Tests" tab and press "Add test" - or open the Tests section's menu and choose "Suggest tests" to add the tests your server's keys, memory and hit rate call for. Suggestions are worked out by rules, so they cost no AI.
Name it, give the key and its database, and choose what the key should be.
Press "Add and run": the test is saved, runs at once and its result opens.
Later, press "Run N tests": the run goes to the background and a bar above the tests shows how far it is. Press "Cancel" on it to stop after the test it is reading; the tests that ran are kept. When it ends you are told how it went, with "Open run".
Press "Run" on one row to run that test at once, or tick several rows to run, switch on, switch off or delete them together.

What changed since it last passed

A failed test is set beside the last time that same test passed, not only the previous run. The panel names what differs: the key went missing, its type or value changed, or it started or stopped expiring. A time to live that only counted down is not a change. A check that never passed has nothing to compare with.

Good to know

Tests only read, so they are safe on a Production server.
Every run is kept in Runs; open one to see what each test expected and what the key held. A switched-off check is left out.
A connection holds at most 50 tests. Adding, editing and deleting tests needs Manage cache connections; running them needs only access to the connection.
A board card linked to a test turns red or green with it; one linked to the connection is red while any test fails.
Runs appear in the Planner on the day they ran. To run them by themselves, use "Run on a schedule" in the Tests section's menu.
Whoever you share a test or run with sees its result only if they can open the connection.
If someone changed a test while you were editing it, saving asks you to reload their version or keep yours.
"Download" on the tests, the runs, one run and the audit trail saves what the screen shows as Excel, PDF, Word, CSV or Markdown.
Narrow the tests with the status chips - Failed, Passed, Not run, Off - or search a name or key, and sort by a column. Keep a narrowing with "Save as view"; the Connections list and the audit trail have views of their own.
Click a test to see it beside the list: what it reads, what it expects, when it last ran, with Run, Edit and Delete. Press J and K to step through the tests; a link from a card or a notice opens the same view.

Run on a schedule

Open the Tests section's menu and choose "Run on a schedule". Choose "How often": every few minutes, every hour, or every day, week or month at a time you pick. A time is kept on the clock of the time zone you choose, so 09:00 stays 09:00 when the clocks change. Press "Start schedule". The menu item appears when the connection has enabled tests and you may change it.
All enabled tests of the connection then run on that schedule. Every few minutes starts within a minute; a daily, weekly or monthly schedule waits for its time. Scheduled runs are marked "Scheduled" in the history.
"History" on the schedule's line lists each turn - passed, failed or could not run, and why - with the run it made. "Run now" brings the next turn forward; it still runs as the person the schedule runs as.
Each run is one of your monitor tests, shared with API monitors. Plan & usage shows how many your plan allows a month.
The schedule runs as you, with your access. It tells you in your inbox when it starts failing and when it passes again.
Switch "On" off to pause it without losing its settings. "Remove schedule" stops it and keeps the runs it already made.
"Also tell a channel" posts a failed run - and one that could not run - to up to three of the workspace's webhooks too, such as a Slack or Microsoft Teams channel, besides the inbox of the person it runs as. Only switched-on webhooks of this workspace are offered; add one in Settings > Webhooks. The message names the connection and how many tests did not hold and links to them, never a value.

Gate a pipeline on the tests

Your build pipeline can run the connection's tests and stop when one does not hold. {{brand}} runs them on its own queue, the same as Run all, so no cache address or password is in the pipeline.

In the pipeline, run: kamocore cache check --connection <the connection's id> --junit cache-results.xml. Every switched-on check runs; --check picks some.
The step fails when a test does not hold, and also when the run could not finish or did not end within --timeout.
The JUnit file and the log name each test and its key, never the value the key held or the value a test expected.
The access token needs the scope CacheTester:write. Ready steps for GitHub Actions, GitLab and Azure Pipelines come with the CLI.

If something goes wrong

A value check fails but looks right: the key may not be a string, or the value differs in letter case or has a trailing space.
Every check fails with one error: the server did not answer. Test the connection.
"There are no tests to run on this connection." / "A connection can hold at most 50 tests."

/help/cache-tester/browsing-and-editing-keys
/help/cache-tester/check-server-health
/help/planner/test-schedules-on-the-calendar