Tusk

The trait that decides it is where the cases come from. Tests derived from real traffic exercise the paths your users actually take, which is a very different set from the ones a developer imagines at half past five on a Friday. For a service with thin coverage and real usage, that distinction is the whole value.

It also means the tool needs your production traffic before it earns anything. Pick it for mature services under load. Pick CodeBeaver for a young codebase nobody is using yet.

Two mechanisms compound. Deriving expectations from what the system does today bakes in whatever it does wrong today, so the suite goes green on a defect and red on the fix. Then maintenance makes it worse: a test that repairs itself when logic changes cannot distinguish an intended change from a regression, which is the one job a test has.

What it does right is closing the loop on itself. It iterates until its own generated tests actually execute, so what lands in the branch runs rather than merely compiles.

1. The pipeline has a clear front and back: captured behaviour goes in, executable tests come out, and the generation loop repeats until they run. 2. The middle is opaque. Nothing published explains how the system decides which observed values are essential to an assertion and which are incidental, which is precisely where a generated suite becomes brittle or vacuous.

2. No measurement accompanies it: no mutation score, no defect detection rate, no comparison against hand-written coverage. For a testing product, that omission is the notable one.

The seat floor is the strategy statement. Requiring two hundred seats before an enterprise conversation means the company is not pursuing mid-market volume; it is pursuing a small number of large contracts, and the free individual tier exists to create internal advocates inside those accounts before sales ever calls.

That is a disciplined motion and a fragile one, because a handful of logos is a concentrated revenue base. Moat: the accumulated test corpus, which is genuinely sticky. Likely acquirer: a testing or quality vendor buying the traffic-capture pipeline. Position: viable, and watch the renewal concentration.

Three thousand a month for my headcount is a legible number, which already puts this ahead of half the shortlist, and a fourteen-day trial of the paid tier means the pilot costs nothing. The output lands as a pipeline check rather than as another dashboard, so adoption does not depend on sixty people forming a habit.

What I do not have is a data answer. Capturing production traffic means customer data enters a supplier's system, and that is a processing agreement and a review, not a checkbox. Approved with conditions: one non-customer-facing service first, with the traffic filter agreed in writing.

A command line is the minimum viable respect and this one has it: I can add generated tests to a local branch from a script rather than clicking through a web interface, which at least makes the tool composable with the rest of my toolchain.

Everything else fails my checks. The licence is proprietary, the model is unnamed, no key of mine substitutes and nothing runs on my hardware. Worse, the input is production traffic, which is the most sensitive material I have, going somewhere I cannot inspect. No fork, no offline path, nothing to keep.