kalku rompe tu código a propósito, un defecto pequeño a la vez, y mira si algún test se da cuenta. El defecto que ningún test detecta es un hoyo en tu suite, y kalku te lo muestra con un archivo, una línea y un diff.
brew install lnds/kalku/kalku 
$ kalku run lib/green.ex --limit 6 --verbose
lib/green.ex:4 compare Green.classify/1
- >=
+ >
covered by 4 tests
No test tells `>=` apart from `>` in
`Green.classify/1`. Add a case at the boundary
where the two sides are equal.
score 60% · 3 killed · 2 survived · 1 compile errorel reporte de una corrida, como aparece en el README de kalku
Qué hace
La cobertura te dice qué líneas se ejecutaron. kalku te dice si algún test se daría cuenta cuando una de ellas está mal.
Un reporte empieza por los sobrevivientes: los defectos que ningún test detectó, cada uno con su archivo, su línea, su diff y una pista. El puntaje viene después, como contexto, porque el sobreviviente es aquello sobre lo que puedes actuar.
$ kalku run lib/green.ex --limit 6
lib/green.ex:4 compare Green.classify/1
- >=
+ >
covered by 4 testsEl puntaje es killed / (killed + survived) y nada más lo mueve. Un timeout, una caída, un wekufe que no compiló o una línea que ningún test alcanza se reportan aparte: nunca cuentan como kill.
$ kalku info outcomes
killed counts towards the score
survived counts towards the score
timeout reported apart from the score
no_coverage reported apart from the score
compile_error reported apart from the score
crashed reported apart from the score
score 60% · 3 killed · 2 survived · 1 compile errorLos wekufe se lanzan en el reni, un espacio de trabajo aislado bajo el directorio temporal de tu máquina. Un proyecto sin configurar se mide tal como está y se deja tal como está: no se escribe nada en él.
$ kalku run lib/thing.ex
kalku: no .kalku.toml in this directory:
measuring it as elixir and leaving it as it is.
What the run keeps is in $TMPDIR/kalku/thing;
`kalku init` sets the project up to keep it.Cada wekufe se carga en un kalku caliente y corre solo contra los tests que lo cubren, hasta el primero que falla. Con kalku serve, los kalku con los que se midió el proyecto sobreviven a la corrida, y la siguiente no vuelve a prepararlo.
$ kalku serve # a 0600 Unix socket
$ kalku cast <wekufe> # re-cast just that one,
# against a warm kalkukalku run --since origin/main mide las líneas que tocó el cambio y bloquea solo por los hoyos que ese cambio introdujo. La deuda antigua no castiga a quien toca el archivo, y los códigos de salida separan «tus tests tienen hoyos» de «kalku no pudo medir».
$ kalku run --since origin/main
# exit 0 measured; nothing to report
# exit 1 your tests have holes
# exit 2 kalku could not measureLos agentes escriben tests rápido; kalku les dice si esos tests prueban algo. Cada sobreviviente llega como un objeto JSON con todo lo necesario para actuar, y kalku mcp sirve cuatro herramientas por stdio. Ninguna suprime, excluye ni ignora nada.
Las pistas salen de una plantilla fija por spell, no de un modelo. Un agente solo puede proponer un mutante equivalente; una persona tiene que aceptarlo.
$ kalku run lib/my_app/parser.ex --format agent
{"wekufe":"c1f3…",
"file":"lib/my_app/parser.ex","line":42,
"enclosing":"MyApp.Parser.next_token/2",
"spell":"compare",
"original":">=","replacement":">",
"covering_count":1,"hint":"No test tells…"}Video
Tres minutos para ver qué es el mutation testing, cómo se usa kalku y por qué importa. Lo cuenta Kalku en primera persona: es brujo, y romper código es su oficio.
Comandos
Un solo binario. Y kalku info documenta los spells, los resultados y los formatos desde el propio programa.
kalku runkalku castkalku showkalku initkalku propose-equivalentkalku acceptkalku rejectkalku infokalku servekalku mcpSe instala con un comando y no necesita configuración. Empieza con kalku run sobre un archivo de tu proyecto.
brew install lnds/kalku/kalku