u/Fit-Paper696

I've been trying to get more serious about testing my own projects lately, and something kept bugging me. I'd let the AI generate a bunch of tests, everything goes green, coverage looks great, and... I still didn't really trust them. Because the tests just assert whatever the code already does. If there's a bug in the code, the test happily locks it in and calls it a day.

That's the thing that got me: 100% coverage means nothing if the assertions are weak. What actually matters is whether the test fails when the code is wrong. And nobody's checking that by hand across 200 generated tests.

Funny enough, a DoorDash eng lead said basically this on NeetCode's channel a couple weeks back: "there's no way to measure assertion quality, and I kind of wish there was." And there kind of is, it's just tedious by hand: you break the code on purpose and see if the test notices. That's mutation testing.

So I started building around that idea. It's called Attest:

1. an LLM proposes property-based tests (FsCheck) for the code in your diff
2. the tool runs them against your real code, anything that fails on working code was a wrong property, tossed
3. then it mutates your code (Stryker.NET) and reruns the survivors, anything still green on broken code proved nothing, also tossed
4. you only see what's left, and each one comes with the exact mutant it caught

The LLM never decides what "passes". That part's all deterministic. It proposes, the machine refutes. If a property can't kill a mutant, you never see it.

Not pretending this is some original galaxy-brain idea, Meta runs the same propose-then-refute loop internally (their ACH paper, FSE 2025) across FB/IG/WhatsApp, and Mutahunter does a version open source. What's different here: properties instead of examples (the stuff that catches race conditions and weird edge cases), it's for .NET (nobody built this here yet), and the LLM never judges anything, every yes/no is deterministic and auditable. Meta's uses an LLM to judge equivalent mutants and gets 47% recall doing it, per their own paper. I didn't want any of that.

Here's a real run, not a cherry-picked demo. Against an actual CliWrap commit:

$ attest --diff 13bc13d~1 --project CliWrap/CliWrap.csproj

Attest: 2 proposed, 1 delivered, 1 rejected, 0 quarantined.

Delivered:  
  [OK] DeconstructMatchesProperties: Deconstructing a BufferedCommandResult  
yields the same values as its ExitCode, StandardOutput and StandardError properties.  
killed by Block removal mutation at BufferedCommandResult.cs:30

Rejected:  
  [Trivial] ImplicitStringConversionEqualsStandardOutput: killed zero mutants.

LLM cost: $0.0448  

One delivered with proof, one thrown out for doing nothing. That rejection is honestly the whole point, it'd rather show you nothing than hand you a test that doesn't test anything.

There's also a --compare-suite mode that skips the LLM entirely and just points the mutation stuff at the tests you already have. Answers "do my current tests actually catch bugs in this diff, or are they decorative?" with a real number. Free if you already run Stryker.

dotnet tool install -g Attest.Cli  
attest --diff origin/main --project path/to/YourProject.csproj  

Runs fully local if you want (Ollama, nothing leaves your machine), or bring your own key. GitHub Action's in there too.

Straight about the limits: it does NOT prove your code does what you meant. If the code has a bug and a property describes that bug correctly, it survives both filters. That's the oracle problem, no mutation score fixes it. That's why every property gets written out in plain English, so you can read it and go "wait, that's not what this should do."

Repo: https://github.com/danellalc/Attest.NET
NuGet: https://www.nuget.org/packages/Attest.Cli

(MIT, v0.2.2, still early and I'm hacking on it actively)

Would genuinely love feedback, especially if you've run mutation testing in CI or tried Meta's ACH. Tell me where it breaks.

Hoje fiquei muito feliz olhando uma coisa que, algumas semanas atrás, eu nem imaginava que fosse acontecer.

Publiquei meu primeiro package no NuGet: o EFCore.AutoSeed.

Ele começou de uma necessidade minha. Toda vez que eu precisava testar uma aplicação com Entity Framework Core, tinha aquele trabalho de criar seed, factory, organizar inserts, cuidar das dependências... e quando o modelo mudava, lá vinha tudo de novo.

Então pensei: vou automatizar isso.

Criei uma ferramenta que lê o modelo do EF Core e consegue popular o banco automaticamente, cuidando da integridade referencial. Uma linha e pronto.

No começo, era só uma ferramenta para eu usar nos meus próprios projetos.
Mas resolvi publicar.
Hoje já são 360+ downloads no NuGet e 47 estrelas no GitHub.
E sinceramente, o que mais me deixou feliz não foram os números.
Foi perceber que uma coisa que eu criei para resolver um problema meu agora está ajudando outros desenvolvedores também.
É uma sensação muito boa abrir o NuGet e ver que alguém, em algum lugar, baixou e está usando algo que você passou horas criando.

É meu primeiro package publicado e com certeza quero continuar evoluindo o projeto.

Obrigado a todo mundo que baixou, deu uma estrela, fez fork, comentou ou simplesmente passou para conhecer. :)

Para quem trabalha com .NET e EF Core:
https://github.com/danellalc/EFCore.AutoSeed
https://www.nuget.org/packages/EFCore.AutoSeed

Primeiro package a gente nunca esquece. ❤️

#dotnet #efcore #opensource #csharp #nuget

Hey! Wanted to share something I've been building: EFCore.AutoSeed, a .NET library that seeds a database straight from your EF Core model.

The problem it solves: every seeding tool out there makes you describe your data model again somewhere else, a CSV file, a factory class, some JSON config. But you already wrote all of that in your DbContext! So it just reads it directly:

await db.AutoSeedAsync(seed: 42, scale: 1_000);

That's genuinely the whole API for the common case. It figures out insertion order itself, resolves foreign key cycles, handles composite keys and inheritance, and generates data that actually looks like production instead of "every customer has exactly 3 orders" uniform nonsense. Same seed always gives you the exact same data too, so a test that passes today doesn't randomly start failing next year.

Posted an earlier version over on r/dotnet a couple weeks back and got genuinely great, detailed feedback, people found real gaps (a lookup table getting flooded with rows it didn't need, a crash on a weird column type, wanting control over specific columns themselves). Went and built all of it, and v2.0.0 is out now:

• exclude any table from seeding entirely (great for lookup/enum tables you manage yourself)
• hand it a custom function for one specific column when the built-in rules can't get it right
• required columns now either get a real generated value or fail with a clear, named error instead of crashing on you

What it is: one line, referentially valid, realistic test data, from a model you already wrote. SQL Server and PostgreSQL, MIT licensed, completely free.

What it's not: not a prod-data anonymizer, not a hosted service, EF Core only (no Dapper, no raw ADO.NET), no other databases yet.

Genuinely had a lot of fun building this, and even more fun watching people find real bugs in it within days of the first post. If you use EF Core and hate hand rolling seed data, give it a shot, and if it breaks on your model I'd love to hear about it :)

NuGet: https://www.nuget.org/packages/EFCore.AutoSeed
CLI tool: https://www.nuget.org/packages/EFCore.AutoSeed.Cli
Source: https://github.com/danellalc/EFCore.AutoSeed