A new tool called IC-Mockery has quietly landed for developers working with the Internet Computer. But rather than adding complexity, it does the opposite. It makes life easier for people building smart services in Rust—a language known for being fast and safe, but sometimes tricky to test.
IC-Mockery focuses on one thing: helping developers test their code before it goes live. The aim is to make sure everything works as expected, without rewriting or reshaping anything just for the sake of testing. You write your logic once, use a simple tag to make it ready for tests, and then check how it behaves when things go right—or wrong.
It’s especially helpful for services that respond to requests over the Internet Computer. These services often have to do several things at once—wait for replies, handle errors, and manage user input. Testing that can get complicated. IC-Mockery steps in to let developers simulate real behaviour, whether they want to check a successful outcome or a mistake.
A small feature in the tool does most of the heavy lifting. It’s a label developers add to their code—more like a note than a rewrite—that quietly prepares it for testing. Behind the scenes, IC-Mockery takes these notes and turns them into a system that supports pretend versions of each function. This way, the original work remains untouched, but tests can still see how it all behaves.
The tool works closely with PocketIC, a testing environment developers already use. That’s what allows the simulations to feel close to real conditions. With both tools working together, it’s possible to check a full service locally—on a laptop or desktop—without uploading it anywhere or involving a network.
There’s a helpful example included with IC-Mockery. It shows a simple greeting service that sends back a message like “Hello, Wizard!” when you give it a name. The test runs through the process: preparing the greeting, then sending it. Using IC-Mockery, the developer can decide in advance what response should come back when each part of the service is called.
In the successful version, everything works as expected. The name “Wizard” returns the correct message, and the result is marked as successful. But there’s also an example of something going wrong. In that test, the same greeting service is forced to return an error. The tool then checks that the error was caught properly. Both cases give developers peace of mind: they know their code handles things well, no matter what the input is.
What’s especially useful is that none of this changes the original code. Developers don’t have to add test-only versions of their services, or rewrite their logic to make room for trial runs. IC-Mockery adds a layer on top, not inside. It keeps things clean, neat, and focused.
Another bonus is that the tests are easy to read. That might not sound like much, but when things go wrong and developers have to track down a mistake, clear and simple test results save hours. With IC-Mockery, the mock setup is written in a clear chain, showing exactly what will happen and when. It also allows different types of outcomes—both success and failure—and supports personalised messages for either.
For people who prefer to get things running quickly, the setup process is also light. There’s no need to install extra tools or change how the project works. Just two short entries are added to the project file, and the tool is ready. It’s open source and lives on GitHub, so developers can send suggestions or help improve it.
The tool also supports different kinds of errors. It doesn’t force developers to use a single style. Whether someone uses a string message, a code, or their own custom method for describing what went wrong, IC-Mockery can understand and work with it.
Because it’s built with modern Internet Computer development in mind, it fits naturally into the way canisters—small smart-service programs—are usually written. Developers don’t need to build complex workarounds to get their code to behave in tests. The tool takes care of that.
Some early testers have already praised how it fits in with PocketIC. That’s because it uses a method that matches what PocketIC expects, letting both tools operate smoothly without clashing. It’s a sign that the team behind IC-Mockery has paid attention to what people are already using, rather than asking them to change everything for a new tool.
The creators have said they wanted to reduce the usual clutter in test code, while keeping all the same safety checks. Their approach seems to hit that mark. By removing extra bits and sticking to what’s needed, they’ve created something light and useful.
One of the stronger points is that it avoids the mess of duplicate code. In older methods, developers often had to copy big parts of their service into the test folder, just so they could add some minor tweaks. IC-Mockery removes that step. You write it once, use the tag, and the tool takes it from there.
There’s room for growth, of course. It’s still early, and developers may want extra features in the future—perhaps better error messages, extra test reports, or simpler ways to run groups of tests. But even as it stands now, it solves a real problem with a quiet sort of efficiency.
For many developers, tools like this mean less time worrying about edge cases and more time building things people will use. The fact that it works well straight out of the box makes it even more appealing.
IC-Mockery feels like something that might become standard—something people reach for without thinking, because it fits so well. It doesn’t overpromise or make too much noise. It does one thing, and it does it well.
Anyone curious to try it out can find it on GitHub now, ready to install, test, and use. There’s full documentation, example code, and an open door for ideas and improvements.
So whether you’re building a greeting service, a chat bot, or something a bit more complex, IC-Mockery might just be the bit of quiet help your project needs.
→ github.com/ic-mockery/ic-mockery
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
🪙 BTC Wallet: bc1pp5kuez9r2atdmrp4jmu6fxersny4uhnaxyrxau4dg7365je8sy2q9zff6p
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
