How we test.

One rule, and it is inconvenient

We run the repo before recommending it. Not the demo, not the quickstart, not the badge in the README: the workflow the project is actually known for, with realistic input, at a commit we name.

This is a slower way to publish. It is the only version of a software recommendation we think is worth reading, because the alternative is a summary of the README with a star rating stapled to it.

What happens before we write a word

1. We decide what would actually prove the tool. Before any code runs, we write down the one workflow a reader would expect us to prove, what counts as success, and how we would independently verify the result. Installing successfully is not that workflow.
2. We pin the commit. A review tests one revision, named in the article. Projects move; our claims stay attached to the version we ran.
3. We try to break it, once. Every review exercises the defining workflow and then something meaningfully different: an error path, an awkward input, an operational limit. The second run is usually where the interesting failure lives.
4. We keep the evidence. Commands, exit codes, logs, traces, screenshots, and the README as it read at that commit.
5. We research past our own run. One machine on one afternoon is a data point, not a verdict. We check releases, maintenance signals, upstream issues, and credible alternatives from dated sources before deciding how much our own result deserves to matter.

The four verdicts

Verdicts are categorical. There is no score, because a number implies a precision we did not measure.

• Try. It did the job. Go install it.
• Adopt with care. It works, and there is a specific cost you should know about first. The article names the cost.
• Wait. The idea is right and the current revision is not ready. Check back.
• Avoid. Not for the job it advertises.

A verdict applies to the commit we tested, for the reader the article describes. A tool that is wrong for a team of forty can be exactly right for one person on a laptop, and the review says which.

What a review cannot tell you

Every review publishes its own limitations, and they are not decorative. We test one revision, on one architecture, for a bounded amount of time. We do not measure sustained production use, we rarely test at scale, and we cannot see a project's future.

If something matters to your decision and we did not test it, the limitations list is where you will find that out. It is the least flattering section of every article and the first one we write.

Tell us we are wrong

If a review misreads your project, tests the wrong thing, or has simply gone stale, email hello@gittested.com. Corrections that change a claim get a fresh review pass, not a quiet edit.

Maintainers who want a repository on the bench can pitch it here. It stays a suggestion.