Why 'should X when Y' rather than just describing the function being tested?

Because it describes behaviour rather than implementation — when the test fails, the runner's output reads as a sentence about what broke ('should return an error when the input is invalid') rather than a function name you then have to go and interpret. That readability is the entire point of the convention.

Test Case Name Generator

Generates a 'should X when Y' test-case description — the naming convention most test runners display in their output — as a starting point or naming-style reference.

How many

Don't repeat what I've already seen

Your result will appear here.

What this generator does

Pairs a behaviour with a condition into one 'should behaviour when condition' sentence — the format most test runners (Jest, Mocha, RSpec and similar) print verbatim in their output, which is exactly why the convention exists: a failing run should read as a sentence about what broke, not a function name someone has to go and look up.

What it builds, and how many ways

Each result is assembled to this shape: [behaviour] + [condition].

behaviour: 20 options
condition: 20 options

Taken together those banks can be assembled 400 different ways, repeating after about 25.

Some results it can produce:

should return an error when the payload is larger than the limit
should trigger the fallback when the cache has been cleared mid-request
should emit exactly one event when the user is unauthenticated
should preserve the original ordering when the field is present but null

A fixed sample so this page stays the same between visits. Your own results are assembled at random, each slot filled independently and each press independent of the last, so the same result can come up twice — past the repeat figure above, seeing one twice is more likely than not.

How to use this tool

Press generate for a test-case name.
Generate again for another one.

Common use cases

Naming a new test case
Test-naming convention reference
Filling a test-plan template

Limitations and good to know

Behaviour and condition are drawn from fixed lists independently of each other and of any real code, so a generated name is a style reference rather than a description of an actual test you've written.
It produces one sentence, not a working test file — the assertions, setup and mocking a real test needs are entirely up to you.
The convention assumes a test runner that displays names verbatim in its output; a framework that doesn't will get less value from the phrasing.

Practical tips

A test name should say what breaks when it fails. Treat the generated name as a template and make the specifics real.
Keep names consistent within a suite; a mixture of naming styles makes a failing run harder to read at speed.

Each part of the result is chosen independently with your browser's cryptographic random number generator, so every option in a bank is equally likely. How Generate Random works.

Frequently asked questions

Why 'should X when Y' rather than just describing the function being tested?: Because it describes behaviour rather than implementation — when the test fails, the runner's output reads as a sentence about what broke ('should return an error when the input is invalid') rather than a function name you then have to go and interpret. That readability is the entire point of the convention.