Regend

When your tests turn red, Regend tells you why, not just that they broke, so you can start fixing instead of investigating.

Comment

What inspired this

In my QA work, I've repeatedly hit the same wall: a test suite goes from green to red, and someone has to read every failing log one by one to figure out why. Most failures fall into a handful of repeating patterns, a renamed field, a broken endpoint, an auth change, a flaky test, a silent logic bug, but every time, a person re-diagnoses them from scratch instead of the tooling helping.

What it does

Regend takes two Newman (Postman CLI) test reports, one from before a code change, one from after, and classifies each broken test into a specific root cause: auth failure, endpoint down, schema change, rate-limit regression, flaky test, or a silent logic bug that status-code monitoring alone would miss. It can detect multiple simultaneous issues on the same request, not just one, and reports honest, signal-based severity instead of marking everything as equally urgent.

How I built it

I built the core classifier myself, then used Codex running GPT-5.6 across several sessions to extend and harden it. Codex added a new failure category early on. Later, after I independently tested the tool against real, messy API data (not just my clean demo fixtures), I found genuine bugs: null response codes being silently swallowed, brand-new tests being misreported as regressions, a classification-ordering bug that mislabeled real outages as merely "flaky," and severity that was hardcoded instead of signal-based. I brought each of these back to Codex to fix, and independently verified every single change myself in a separate terminal before accepting it into the project.

Challenges I faced

The biggest one: real-world Newman data doesn't behave like clean demo fixtures. Testing against actual staging APIs surfaced cascading failures from one root cause, shared test state that broke on reruns, and multi-value status assertions my first version couldn't parse. Rather than hide these limitations, I documented them honestly in the README, what the tool needs to classify accurately, and what will produce noisy results, so anyone using it knows exactly where it's reliable.

What I learned

Nothing ships perfect the first time, and that's fine. Testing this tool against real messy data instead of just my clean demo taught me to actually read errors carefully instead of assuming they meant what I expected, several "obvious" bugs turned out to be something else entirely once I looked closely. I also learned the value of working smart, not just hard: verifying each fix myself in a separate terminal, rather than trusting output blindly, caught real problems before they shipped and saved time overall.

Built With

Share this project:

Updates