In Part 2 of our Typemock Architecture series, we explore the inner workings of the .NET Isolator Engine: the runtime component that gives the Typemock architecture its unique ability to mock statics, privates, sealed methods, legacy systems, and third-party code without rewriting anything.
In Part 1 we covered where Typemock installs, how the desktop layout works, and how Visual Studio, test runners, and CI connect to the mocking engine.
Now it’s time to zoom into the real heart of the typemock architecture:
the Isolator Engine the component responsible for static mocking, constructor interception, sealed method overrides, and deep legacy testing that other frameworks simply cannot do.
This is the part of Typemock developers describe as:
“Wait… it mocked THAT?!”
Let’s open the hood.
🔥 1. The Problem: Traditional Mocking Lives Outside the Runtime
Before diving into Typemock, it’s worth understanding why other frameworks can’t do what Typemock does.
Traditional mocks depend on:
- Dependency injection
- Interfaces
- Virtual methods
- Reflection
- Context objects
- Manual refactoring
- and sometimes ugly workarounds
This means they fail on:
❌ Static methods
❌ Sealed classes
❌ Private methods
❌ Hidden dependencies
❌ Legacy systems
❌ Third-party SDK calls
❌ Code you can’t change
This is not because they are “bad.”
It’s because they work at the language level, not the runtime level.
Typemock is different.
🧠 2. Typemock Enters at the Runtime Level (Not the Language Level)
Typemock integrates into the .NET runtime using the CLR Profiler API, a low-level interface designed for performance monitoring – not mocking.
But with deep engineering, Typemock uses this interface to redirect execution, not just observe it.
This is the architectural breakthrough that powers Typemock.
🧬 3. The Lifecycle: How the Isolator Engine Loads Into Your Test Process
The best way to understand the Isolator Engine is through its lifecycle.
When you run:
|
1 2 |
dotnet test |
Here is the sequence that follows:
Step 1: The Test Runner Starts a Clean Process
A new process launches (testhost.exe, vstest.console.exe, etc.).
This is an isolated space: no pollution, no global hooks, no background services.
To understand how .NET test hosts work at a low level, Microsoft’s documentation provides a useful overview.
Step 2: Typemock Registers as a CLR Profiler
Typemock tells the CLR:
“Notify me every time a method is JIT compiled.”
This is a legal, documented API in .NET not a hack, not a patch.
Step 3: CLR Begins JIT Compilation
As the CLR encounters each method in your test run, it begins compiling them.
This is where the Typemock architecture comes alive.
Step 4: Typemock Intercepts and Rewrites IL In Memory
When a method is about to be compiled, Typemock sees its IL and can:
- Replace the call target
- Rewrite instructions
- Override return values
- Redirect constructor calls
- Modify behavior of sealed/private/static members
- Inject fake logic
All in memory, before it becomes machine code.
Nothing touches your binaries.
Nothing touches your source.
Nothing persists after the test.
This is why InfoSec teams love Typemock.
Step 5: Typemock Hands the Modified IL Back to the CLR
The CLR compiles the IL into native code – the code that now reflects your fake behavior.
Step 6: The Test Runs with Full Control
This is the moment you get:
|
1 2 3 |
Isolate.WhenCalled(() => File.ReadAllText("settings.json")) .WillReturn("fake-config"); |
Or:
|
1 2 |
Isolate.Fake.StaticMethods(typeof(LegacyManager)); |
Or even:
|
1 2 3 |
Isolate.NonPublic.WhenCalled(legacyObject, "CalcInternalScore") .WillReturn(999); |
No wrappers.
No interfaces.
No constructor injection.
No code redesign.
Your code stays your code.
Step 7: Process Ends → Engine Unloads
No residue.
No DLL changes.
No registry keys.
No locked files.
No background tasks.
Your system remains clean.
🎛️ 4. What the Isolator Engine Actually Does at Runtime
Let’s break it down in technical detail.
✔ Intercepts method calls
Before they become machine code.
✔ Rewrites IL instructions
Using controlled rewriting routines inside the JIT callback.
✔ Substitutes behavior on demand
Returning what your test instructs.
✔ Tracks execution paths
Used for Coverage + SmartRunner.
✔ Does not touch disk
All changes vanish when the process ends.
✔ Is fully deterministic
Tests behave identically in:
- VS
- CLI
- CI
- Docker
- Build servers
- Agent machines
This is one of the biggest architectural advantages of Typemock.
🧵 5. A Visual Metaphor: The JIT as the Gatekeeper
If you imagine the CLR as a gatekeeper, Typemock stands next to it and says:
“Before you compile this method, I want to adjust something.”
The CLR says:
“Okay, I’ll wait.”
Typemock modifies it.
CLR compiles the final version.
Execution proceeds normally except now it follows your rules.
This is the Typemock architecture in one sentence:
We intercept execution at the moment it matters and nowhere else.
🔒 6. Why This Technique Is Safe (Enterprise-Level)
Large enterprises adopt Typemock because:
✔ No code modification
Your source code remains unchanged.
✔ No assembly rewriting on disk
You never risk corrupted binaries.
✔ No global hooks
No startup processes.
No runtime dependencies.
✔ No elevated permissions needed
Standard user rights are enough.
✔ No impact outside the test process
Production is never touched.
🧪 7. Standard Mock vs Typemock Runtime Version
❌ Standard Mock: Language-Level Limitations
|
1 2 3 4 5 6 |
var mock = new Mock<ILoginService>(); mock.Setup(s => s.Validate()).Returns(true); var sut = new Authenticator(mock.Object); Assert.IsTrue(sut.Authenticate()); |
You must:
- Inject dependencies
- Create interfaces
- Rewrite architecture
- Replace constructors
- Do design gymnastics
✅ Typemock Mock: Runtime-Level Freedom
|
1 2 3 4 5 6 |
Isolate.WhenCalled(() => LegacyLoginService.Validate()) .WillReturn(true); var sut = new Authenticator(); Assert.IsTrue(sut.Authenticate()); |
No injection.
No redesign.
No interface ceremony.
Just control.
This is the power of going runtime-deep.
🔮 8. Why This Matters for Teams
Developers → ship faster
Architects → don’t force redesigns
DevOps → predictable CI behavior
InfoSec → zero footprint & no global code rewriting
Leaders → can test what used to be untestable
This is why Typemock has been adopted in:
- Banking
- Finance
- Aviation
- Healthcare
- SaaS
- Gaming
- Embedded
- Defense
Teams with real, messy, legacy, high-stakes systems.
Because Typemock’s architecture handles real-world complexity not theoretical code purity.
🎯 Conclusion: The Isolator Engine Is the Core of the Typemock Architecture
Typemock works differently because it is architected differently.
It doesn’t depend on:
❌ Interfaces
❌ Virtual methods
❌ DI containers
❌ Design purity
❌ Test-only wrappers
It depends on:
✔ CLR JIT interception
✔ In-memory IL rewriting
✔ Controlled runtime substitution
✔ Clean test-process isolation
This is what makes Typemock capable of mocking the “impossible.”
🚀 Want to See the Engine in Action?
👉 Download the Isolator Engine and experience the freedom:
https://www.typemock.com/download-isolator/
