We’ve been sneakily improving our manual verification process for server PRs over the past few weeks. Sneakily, because it hasn’t been planned, just experiments snuck into the gaps here and there. One of those experiments happened today.
Here’s how it works:
- Preview environments: We’ve had this for a while, and it’s important. Render.com deploys a preview environment for each pull request, so reviewers can hit real endpoints without setting up locally. (For us, it’s on-demand because not every PR needs to be tested against a preview.)
- AI-generated test commands: When preparing a PR, the dev can ask the AI to generate cURL commands that exercise the new changes. These can be included directly in the PR description as code blocks, making life easier for the reviewer.
These two things together are a huge win over the old:
- Stash your stuff
- Checkout the PR branch
- Open an HTTP client
- Set up requests for the new endpoints, etc.
And today, I wanted to remove the last bit of friction, copy-pasting each test command individually. This isn’t a huge deal, but if there are 4 commands to run that contain a lot of JSON, it can get confusing to remember what’s been done and what hasn’t yet. So Claude and I vibe-coded a little tool to make this faster: prquicktest—a CLI that reads a PR description, finds the Testing section, and walks you through running each code block interactively.
How It Works
Point it at a PR URL: (make sure the github cli is installed)
npx prquicktest https://github.com/owner/repo/pull/123
Or a local markdown file:
npx prquicktest ./testing-instructions.md
The tool scans for a ## Testing (or ## Tests or ## Test) section and extracts all the code blocks. It then walks through them one at a time, showing you each block and asking if you want to run it.
For example, if my PR had this in the description:
## Testing
Fetch Luke Skywalker's info:
```bash
curl -s https://swapi.dev/api/people/1/ | jq .name
```
And then I ran npx prquicktest <pr link> then I’d see something like this:
Found 1 code block(s) in Testing section.
─────────────────────────────────
## Testing
Fetch Luke Skywalker's info:
┌─ [1/1] bash ─────────────────────
curl -s https://swapi.dev/api/people/1/ | jq .name
└─────────────────────────────────
Run this block? [y/N/q]
Type `y` to run, `n` to skip, or `q` to quit entirely.
Conditions: Verify What You See
After a code block, a line starting with check:, condition:, or check for: will show the reviewer a prompt to about what they should verify:
## Testing
Fetch Luke Skywalker's info:
```bash
curl -s https://swapi.dev/api/people/1/ | jq .
```
check: Response includes name "Luke Skywalker"
check: Response includes homeworld URL
Then fetch his homeworld:
```bash
curl -s https://swapi.dev/api/planets/1/ | jq .name
```
check: Returns "Tatooine"
When you run the code block, prquicktest shows the output, then prompts you for each condition:
┌─ [1/1] bash ─────────────────────
curl -s https://swapi.dev/api/people/1/ | jq .
└─────────────────────────────────
Run this block? [y/N/q] y
├─ output ─────────────────────
{
"name": "Luke Skywalker",
"height": "172",
"homeworld": "https://swapi.dev/api/planets/1/",
...
}
└─ ✓ success
┌─ Condition ─────────────────────
│ Response includes name "Luke Skywalker"
└─────────────────────────────────
Was this condition met? [y/N]
At the end, you get a summary table:
═══════════════════════════════════
Condition Summary
═══════════════════════════════════
✓ PASS Response includes name "Luke Skywalker"
✓ PASS Response includes homeworld URL
✓ PASS Returns "Tatooine"
───────────────────────────────────
Passed: 3 Failed: 0 Skipped: 0
Done!
Supported Languages
Right now it handles the basics:
- bash, sh, shell — runs with
bash -c - javascript, js, node — runs with
node -e - python, py, python3 — runs with
python3 -c
Other code blocks (like json examples) are skipped automatically.
Installation
Requires Node.js 18+ and the GitHub CLI (for fetching PRs).
npm install -g prquicktest
Or just run it directly:
npx prquicktest <pr-url>
Why Bother?
It’s a small thing. But when testing instructions are easy to run, they actually get run. And when they include explicit conditions to check, reviewers catch more issues.
The tool is open source under GPL-3.0 if you want to poke around or contribute.