rut: A Python Test Runner That Skips Unaffected Tests

schettino72 — Sun, 08 Feb 2026 05:05:13 +0000

Nothing bugs me more than waiting for the computer to do something I already know is pointless. Changed one file and watching 500 unrelated tests run? That's wasted time I'm not getting back.

In 2008, I created doit — a build tool that tracks file dependencies and only rebuilds what changed. Same idea as make, but for Python workflows.

Then I built pytest-incremental — applying the same principle to tests. If you change utils.py, only run tests that depend on it. Skip the rest.

Now there's rut.

Why another test runner?

pytest-incremental requires pytest. Its plugins are great individually, but combining multiple plugins into a consistent experience is hard — they step on each other, configuration gets fragile, and debugging interactions is painful.

Codebases have grown orders of magnitude, and AI-assisted workflows are accelerating that further. We need new test infrastructure to keep up. Parallelization helps, but fast turnaround is still king — skipping what doesn't need to run beats running it faster.

rut is simple:

pip install rut

rut              # run all tests, build dependency graph
rut --changed    # run only affected tests

How it works

rut analyzes your import graph. If api.py imports models.py which imports utils.py, and you change utils.py, rut knows to run tests for all three.

Tests for modules that don't depend on utils.py? Skipped.

For well-structured codebases, this typically means 50-80% fewer tests on incremental runs.

Features

Dependency-aware ordering: foundational tests run first, so failures point to root causes
Async support: built-in, no plugins needed
--dry-run: see what would run without running it
unittest compatible: drop-in replacement for python -m unittest

Try it

pip install rut
rut

GitHub

Building MCPBench #1: Why we’re building it + first progress

schettino72 — Mon, 20 Oct 2025 07:59:23 +0000

Hi folks — I’m building MCPBench to make it easier to discover and evaluate MCP servers. The goal is simple: reduce the time from “what’s out there?” to “I found the right server”.

The problem I keep hearing

“Will this MCP really work for my use case?”
“Do we have any real data on these integrations?”
“Will the MCP work in conjunction with my system prompt & other context?”

What shipped this week

A faster server browser with richer filters and “star” saves
Per‑server pages with packages/remotes and quick links

Why this matters

MCP is growing fast; a clear map helps authors and users meet in the middle
Consistent classification unlocks better filters and future compare views

Open question for you

Does our deployment framing (localhost / self‑hosted / hosted) match how you think about MCP servers?
If not, what would you change or add?

What’s next

Visualizations of registry (leaderboards, weekly trends)
Details on available tools
Drafting “config/install” snippets to get to first run faster
A lightweight compare view for side‑by‑side evaluation

Try it and tell me what breaks

Browse servers: mcpbench.ai

I’d love your feedback in the comments — or ping me on X/LinkedIn. If you publish an MCP server and want it highlighted, drop a link and what makes it special.