$ protest run tests:session -n 4

Avec un collègue, on revenait tout le temps sur le côté magique de pytest. On adore le framework, mais les fixtures résolues par nom, pas de types, pas de Ctrl+Click — ça gratte.

Je voulais un truc plus déclaratif, dans l'esprit de ce que fait FastAPI avec la DI.

Depuis la v0.2.0, ProTest traite les évals LLM comme des citoyens de première classe : une éval, c'est juste un test qui renvoie une valeur — scorée au lieu d'assertée. Mêmes fixtures, même DI, même parallélisme ; juge, scoring et short-circuit en natif. Tes évals vivent à côté des tests qu'elles accompagnent, pas dans un framework à part.

Le projet a pris de l'ampleur vite. Thread pools, exit stacks async, bus d'événements, scoping en arbre... Du async bas niveau qu'on touche jamais en faisant des APIs.

Pour valider l'approche, j'ai réécrit de gros morceaux des suites de tests de pydantic, httpx et starlette avec ProTest. Résultat : sur httpx et starlette, les tests passent 20-30% plus vite que les suites officielles, grâce à l'async natif.

v0.2.0 releasée (release-please, CI, docs). Et surtout, dogfoodé en continu : ProTest est le harnais d'évals de Felix↗, mon assistant de continuité — chaque comportement de son moteur LLM y est une éval rejouable.