Playbook
Tasteful Skills
“Tasteful Skills” argues that the best agent skills are not documentation or best-practice lists.
Back to Podcast Digest
On .NET Live - Bitchiko Tchelidze
TL;DR
Impostor exists because mock performance becomes real money at scale — Bitchiko Tchelidze built the .NET mocking library after seeing large test suites where replacing runtime proxy generation could shave minutes off CI pipelines.
The core technical bet is source generation instead of reflection-based runtime proxies — unlike Moq, NSubstitute, and FakeItEasy, Impostor generates mock implementations at compile time, which he says delivers roughly 5–10x speedups and stronger compile-time safety.
Tchelidze deliberately copied familiar ideas from Moq instead of inventing a new mocking style — his pitch is that developers can switch without a big learning curve, with readable calls like
Imposter().Sum(Arg.Any<int>(), Arg.Any<int>()).Returns(5)rather than a more abstract API.A big selling point is strongly typed callbacks and returns that fail at compile time, not runtime — he shows how traditional libraries can let signature mismatches compile, while Impostor catches wrong parameter counts or types as compiler errors.
The project is early, MIT-licensed, and explicitly open for contributors — first released in January after roughly six months of work starting in June, it already supports methods, properties, indexers, events, explicit/implicit modes, and class mocking for virtual members.
The long-term ambition is bigger than faster interface mocks — Tchelidze says he’s exploring IL weaving so Impostor could eventually mock static and non-virtual methods, a gap he says no single library currently covers cleanly.
The Breakdown
A chaotic intro, then straight into why another mocking library exists
The show opens with the hosts joking about the over-the-top promo music before Maya Wenzel introduces guest Bitchiko Tchelidze, a software architect and hands-on engineer with 10 years in .NET. He wastes no time on the obvious question: why build yet another mocking library when Moq, NSubstitute, and FakeItEasy already exist? His answer is simple and practical — performance, especially when your test suite is huge and mocks are everywhere.
The main pitch: source-generated mocks instead of runtime proxy magic
Tchelidze explains that most popular mocking libraries rely on runtime proxy generation via reflection, which is flexible but slower. Impostor moves that work to compile time using source generators, so the mock type already exists by the time tests run. He’s careful not to oversell it as a miracle for every project: if your codebase is small, you may not notice much, but in large CI pipelines the gains can add up to minutes.
A demo built around ergonomics, not just speed
The live code walkthrough is all about readability. Instead of new Mock<ICalculator>() and layered setup syntax, he shows an API where you create an imposter directly for ICalculator, call the method you want to mock, and chain things like Returns, Then, or Throws. The hosts immediately notice that it reads cleanly, and Tchelidze says that was intentional — he borrowed familiar mental models from Moq so people don’t have to relearn mocking from scratch.
Verification, sequences, and the subtle compile-time win
He walks through basic mocking patterns: matching with Any, sequential setups, throwing on the third call, and verifying invocation counts with helpers like “called once.” Then he lands on what sounds like his favorite feature: strongly typed callbacks and return factories. Because the code is generated at compile time, Impostor can catch signature mismatches early — wrong parameter types, wrong parameter counts, and refactoring fallout that older runtime-based libraries might only explode on later.
Benchmarks, docs, and what the library already covers
After a quick pause for questions, he pulls up the repository and benchmark charts. On a simple mock scenario, he says Impostor is around 10x faster on single calls and generally 5–10x faster on timing than Moq, NSubstitute, and FakeItEasy, with memory numbers looking solid too. He also highlights that this isn’t just a toy: it supports methods, properties, indexers, events, explicit vs. implicit mocking modes, and class mocking as long as members are virtual.
Why he built it, how long it took, and what comes next
When asked what sparked the project, he points to a real codebase with lots of unit tests and his excitement about source generators as a natural fit for mocking. He says he started around June and released the first version near the end of December, with method mocking alone taking months once edge cases like out, params, Task, and other ugly details showed up. Looking ahead, he wants to optimize the generator further and explore weaving or IL rewriting so Impostor could eventually mock static and non-virtual methods too — the kind of “best of both worlds” capability he says doesn’t really exist in one library today.
Share
Keep Reading
Two Ways to Follow
The Weekly Echo. The inbox-shaped summary of what mattered.
New editorials announced here.
