Random Boolean Generator

Both branches, or only the one you thought of

Most conditional code is written with one path in mind and tested along that path. The other branch exists, compiles, and has never run with realistic data. Boolean test values are the cheapest way to make sure both sides get exercised before a user finds the one that does not work.

Generating them in bulk matters more than it sounds. A single true and a single false prove the code runs. A few hundred mixed values run every combination of preceding state with each branch, which is where the interesting failures live.

Bias is how you model reality

Real-world booleans are rarely even. A payment fails perhaps one time in fifty. A user opens a notification perhaps three times in ten. A rare error path might occur once in a thousand requests. Testing all of these at an even split misrepresents every one of them.

Setting the bias lets a fixture match the shape of the thing it stands for. That matters when the code under test behaves differently at different rates — retry logic that is fine at a 1% failure rate and collapses at 40%, or a queue that drains comfortably until the failure rate crosses a threshold and then never catches up.

The rare cases deserve particular attention. A one-in-a-thousand branch is, by definition, almost never taken during development, so it is the branch most likely to contain an untested mistake. Setting the bias to make it common is the fastest way to find out whether it works at all.

Independent draws do not balance themselves

Set the bias to 50, generate ten values, and you will frequently see seven of one and three of the other. This is not a fault in the generator. Each value is drawn independently and knows nothing about the ones before it, so short runs are lumpy.

The proportion converges on the setting as the count grows — a thousand values will sit close to the target — but there is no mechanism forcing balance in a small sample, and expecting one is the gambler’s fallacy in another costume. If you specifically need an exact split, generate a list of the right composition and shuffle it instead.

Output formats and the cost of mismatch

The string “false” is truthy in most languages. So is “0” in some. A boolean written in the wrong format for its destination does not usually fail loudly — it silently evaluates to true and the bug surfaces somewhere unrelated, days later.

Producing the format the target actually expects avoids the conversion step where that mistake gets made. JSON wants unquoted true and false. A database column probably wants 1 and 0. A YAML configuration file may accept yes and no, and may also interpret them in ways that surprise you.

Reproducible fixtures

Seeded mode makes the output deterministic, so a test that fails against generated booleans can be re-run with exactly the same values. Recording the seed alongside the failure turns an intermittent report into something a developer can actually work on.

Privacy

Values are generated in your browser. Nothing is transmitted, stored or logged.

Booleans in databases and APIs

Boolean columns are one of the more inconsistently handled parts of any schema. Some databases have a genuine boolean type; others store 1 and 0 in a small integer; some historically used single characters. A fixture that assumes one representation and meets another produces values that are technically stored and semantically wrong.

The same applies at API boundaries. JSON has real booleans, but form encoding does not — a checkbox arrives as the string “on” or is simply absent, and code that treats absence as false while treating an unchecked box as an explicit false will disagree with itself somewhere.

Generating values in the exact format the target expects is the cheapest way to avoid discovering this later.