Isolator++ 5.4.3 focuses on one thing:
making C++ unit testing stable across modern compilers so developers can continue testing their code without friction.

This release expands compiler support and improves deployment reliability while continuing to deliver what Isolator++ is known for: powerful mocking for real-world C++ code.

Reliable C++ Unit Testing Across Modern Compilers

To support modern development environments, Isolator++ 5.4.3 adds support for the latest GCC and Clang compilers.

GCC support

• GCC 11
• GCC 12
• GCC 13
• GCC 14
• GCC 15

Clang support

• Clang 11 through Clang 21

Why this matters

Many teams upgrade compilers for:

• performance improvements
• new language features
• security updates
• CI infrastructure updates

With this release, teams can upgrade toolchains without worrying about breaking their unit tests or mocking framework.

For teams practicing Agile development and continuous integration, this means smoother builds and fewer surprises.

Learn more about these toolchains:
Clang compiler project: https://clang.llvm.org/
GCC compiler documentation: https://gcc.gnu.org/

Mocking Non-Virtual Methods in C++ Unit Testing

One of the biggest challenges in C++ unit testing is testing code that was not designed for mocking.

Many frameworks require:

• virtual methods
• interfaces
• dependency injection
• refactoring legacy code

But real-world C++ code often contains non-virtual methods, making traditional mocking impossible.

Isolator++ solves this problem.

Developers can isolate behavior without modifying production code.

Production Code

class CurrencyService
{
public:
    int GetExchangeRate()
    {
        // Imagine this calls an external API
        return 5;
    }    

    int Convert(int usd)
    {
        return usd * GetExchangeRate();
    }
};

Unit Test with Isolator++

TEST(CurrencyServiceTests, Convert_UsesExchangeRate)<br>{<br>    CurrencyService service;<br>    Isolator a;<br>    a.CallTo(service.GetExchangeRate()).WillReturn(3);<br>    int result = service.Convert(10);<br>    ASSERT_EQ(result, 30);<br>}

What this test achieves

The test isolates the dependency by replacing the behavior of a non-virtual method.
Instead of calling the real implementation:

GetExchangeRate()

the test substitutes:

WillReturn(3);

This allows developers to test logic independently from external dependencies, making tests:

• faster
• deterministic
• easier to maintain

This ability to mock non-virtual methods is one of the key reasons teams adopt Isolator++ for C++ unit testing.

Why Teams Choose Isolator++ for C++ Unit Testing

Testing complex or legacy C++ code can be difficult when dependencies are tightly coupled.

Isolator++ helps teams introduce unit testing into real-world codebases by allowing developers to mock:

• non-virtual methods
• static functions
• global functions

This allows developers to test existing systems without rewriting the architecture, making it easier to improve:

• code quality
• test coverage
• development speed

As development tools evolve, including AI-generated tests and automated validation, having reliable isolation becomes even more important. You can read more about this in our article on AI and unit testing

Download Isolator++ 5.4.3

If your team is upgrading compilers or modernizing your development environment, this release ensures your mocking and C++ unit testing workflow continues to run smoothly.

Download the latest version here

Final Thoughts

The goal of every Isolator++ release is simple: remove obstacles to effective C++ unit testing.

With expanded GCC and Clang support, improved deployment reliability, and powerful mocking capabilities, Isolator++ 5.4.3 helps developers test complex C++ systems with confidence.

The post C++ Unit Testing Made Easier: Isolator++ 5.4.3 Adds Support for Modern Compilers appeared first on Typemock.

Recently, several articles have suggested that AI may signal the end of traditional unit testing.

• “AI Is Forcing the End of Unit Testing” (Analytics India Magazine)
• “How AI Coding Makes Developers 56% Faster — and 19% Slower” (The New Stack)
• “AI Tools Make Coders More Important, Not Less” (Harvard Business Review)
• “AI-First Testing Is a Dangerous Approach to Code Quality” (HackerNoon)

Some argue AI will replace unit testing.
Others warn that AI-first testing is dangerous.
So which is it?

The answer is simpler:

AI does not end TDD.
It exposes whether you ever understood it.

The Speed Illusion in AI Unit Testing

AI can generate:

• 100 tests in seconds
• Full coverage
• Edge cases
• Happy paths

This feels powerful.
And it is.
But speed is not isolation.
Coverage is not protection.

AI optimizes for plausibility and pattern matching.
Unit testing optimizes for correctness and boundaries.

If you confuse the two, you inflate confidence without increasing quality.

AI Unit Testing Is Not New (We’ve Been Doing It Since 2011)

Automated test generation is not new.
We introduced AI-generated unit tests back in 2011.
Long before LLMs became mainstream.
After more than a decade of real-world use in .NET and C++ systems, some patterns became very clear.

Common Problems in AI Unit Testing

Duplicate Tests Multiply

AI generates variations of the same test:

• Slightly different inputs
• Same behavior being asserted
• No new coverage meaning

Coverage numbers go up.
Signal does not.
Duplicate tests create noise.
And noise hides risk.

Noisy Tests Look Impressive

AI often:

• Asserts too many values
• Verifies internal implementation
• Includes unnecessary setup
• Tests behavior that doesn’t matter

The tests pass.
But they don’t survive refactoring.
A good unit test fails for one reason.

If your suite collapses after a harmless refactor, your tests were coupled not protective.

Stapling Bad Code Into Tests

This is the most dangerous pattern.

AI frequently:

• Uses production logic as reference
• Mirrors the same algorithm in assertions
• Encodes current bugs into tests

The result?

The test “proves” the code works
because it repeats the same logic.
That is not validation. That is duplication.

False confidence is worse than missing tests.

Its too easy

And here’s another uncomfortable truth:

Because writing tests is now easy, developers often just delete failing tests and ask AI to rewrite them.

The test fails.
It’s quicker to regenerate than to investigate.

But when you rewrite a failing test without understanding why it failed, you may be deleting the only thing protecting you.

AI makes rewriting trivial.

It does not make debugging optional.

Where AI Is Actually Excellent

AI shines when:

• Working with legacy code
• Creating a safety net before refactoring
• Exploring untested paths
• Generating scaffolding quickly

For large legacy C++ or .NET systems, this is extremely valuable.
AI can give you a starting point in minutes.
But that starting point must be reviewed.

How to TDD With AI (The Practical Way)

Instead of letting AI “write your tests,” use it deliberately.

Here’s a workflow that works.

Step 1: Prompt for Behavior Exploration

Ask AI:

“Find all cases for this behavior.”
“List normal, edge, and failure scenarios.”

This forces thinking about intent before code.

Step 2: Generate Unit Tests Using Seams

Prompt:

“Write unit tests using the seams (a, b, c).
Do not call real infrastructure.
Isolate external dependencies.”

Be explicit. If you don’t define boundaries, AI will happily cross them.

Isolation must be intentional.

Step 3: Implement

Now implement against the tests.

If tests break during simple refactoring, they were tied to implementation details.

Refactor both.

Repeat.

The Developer’s Role Has Shifted

Traditional TDD:

Write test
See it fail
Implement
Refactor

AI-assisted TDD:

Describe behavior 
AI generates tests
Review
(AI) Implements
Refactor safely

As a human you must review carefully:

Are we testing behavior, not implementation?
Is the test isolated?
Does it hit real services?
Are assertions meaningful?
Are there duplicate tests?

You are no longer just writing tests, you are reviewing meaning.

The Real Risk of AI Unit Testing

The real risk (as with all AI) is inflated confidence.

AI increases:

• Test count
• Coverage percentages
• Speed

But it also increases:

• Duplicate tests
• Noisy tests
• Shallow assertions
• Hidden coupling

AI multiplies whatever discipline you already have.
If your testing culture is weak, AI scales weakness.
If your testing culture is strong, AI scales strength.

Final Thought on AI Unit Testing

Writing tests is now easy.
Writing meaningful tests is still rare.

TDD in the AI era is not about typing faster.

It is about:

• Clear behavior definition
• Strong isolation
• Intentional boundaries
• Reviewing what your tests actually prove

AI does not end unit testing. It forces us to do it properly.

Learn more about Continuous Unit Testing in 2026

The post AI Unit Testing: How to TDD With AI appeared first on Typemock.

Software development in 2026 moves at a pace that would have been difficult to imagine only a few years ago. Release cycles are short, refactoring is continuous, and AI-assisted development allows teams to produce more code than ever before. While this speed enables faster innovation, it also increases the risk of defects silently making their way into production.

Continuous unit testing has become a necessary response to this reality. Instead of treating testing as a final step before release, continuous unit testing provides ongoing feedback throughout development, helping teams detect problems early and maintain confidence in their code as it evolves.

From Periodic Testing to Continuous Feedback

Traditional unit testing often focuses on running tests at specific milestones, before a merge, at the end of a sprint, or prior to release. In fast-moving projects, this approach is no longer sufficient.

Continuous unit testing shifts the focus to constant feedback. Tests are executed automatically on every commit, during local development, and as part of nightly and pre-release builds. When a regression is introduced, it is detected immediately, while the developer still remembers the change that caused it. This tight feedback loop reduces both the cost and complexity of fixing defects.

Why Continuous Unit Testing Matters More Today

Several changes in how software is built have made continuous testing more important than ever.

First, code changes are more frequent. Agile practices encourage regular refactoring and incremental improvements, increasing the chance of unintended side effects.

Second, AI-assisted development has altered how code is written. While AI tools can generate large amounts of code quickly, they do not fully understand business rules or system context. Unit tests act as a safeguard, ensuring that generated code behaves as expected.

Finally, modern systems are rarely homogeneous. Many projects combine managed code, native components, legacy modules, and external services—making isolation and repeatable unit testing significantly harder than in greenfield projects. In such environments, manual testing and late-stage validation cannot keep up.

The Hidden Cost of Unstable Tests

Most teams already have unit tests, but not all tests are equally useful. Tests that depend heavily on internal implementation details tend to break during refactoring, even when the system’s behavior remains correct.

Over time, unstable tests create friction. Developers spend time fixing tests instead of improving the product, and failing tests begin to be ignored. This erodes trust in the test suite and undermines the purpose of continuous testing.

When that trust is lost, even a comprehensive test suite can become a liability rather than a safety net.

The effectiveness of continuous unit testing depends not only on how often tests run, but also on how well they are designed.

In practice, instability often comes from inadequate isolation. When unit tests interact with file systems, system clocks, static state, native libraries, or external services, they become brittle and unpredictable.

Effective isolation requires more than basic test doubles, it often demands the ability to intercept, mock, or replace behavior at runtime, especially in legacy or mixed-language codebases.

In mature systems, another risk appears: tests may continue to pass while no longer validating meaningful behavior. Assertions become incomplete, dependencies shift, or tests succeed despite changes they were meant to detect. In such cases, continuous feedback must apply not only to the code, but to the tests themselves.

Focusing on Behavior and Isolation

Stable unit tests focus on observable behavior rather than internal structure. They isolate the code under test from external dependencies such as databases, services, file systems, or system time.

By isolating decision points and validating outcomes, tests become more resilient to refactoring and architectural changes. They also run faster and produce consistent results, essential when tests are executed frequently.

The following examples illustrate behavior-focused unit tests, where dependencies are isolated and the test asserts only the observable outcome.

A Simple Example in .NET

[Test]
public void Should_CalculateDiscount_WhenUserIsPremium()
{
    var userService = Isolate.Fake.Instance<IUserService>();
    Isolate.WhenCalled(() => userService.IsPremium("alice"))
           .WillReturn(true);

    var calc = new PriceCalculator(userService);
    var result = calc.GetPrice("alice", 200);

    Assert.AreEqual(180, result); // 10% discount
}

This test verifies a business rule rather than an implementation detail. As long as the observable behavior remains correct, the test continues to pass, even if the internal logic of the calculator changes.

A Comparable Example in C++

TEST(PriceTests, ShouldCalculateDiscountForPremiumUser)
{
    Isolate a;
    a.CallTo(UserService::IsPremium).WillReturn(true);

    PriceCalculator calc;
    auto price = calc.GetPrice("alice", 200);

    ASSERT_EQ(price, 180);
}

Here again, the test validates the outcome without depending on how the result is produced, making it robust across refactoring and platform changes.

Making Continuous Unit Testing Work in Practice

To benefit from continuous unit testing, teams need to integrate it into daily workflows.

Tests should run automatically in continuous integration pipelines and be easy to execute locally during development. Developers should receive feedback quickly, ideally within seconds or minutes of making a change.

Equally important is measuring what matters. Coverage metrics are useful, but the priority should be validating critical business logic rather than maximizing line counts.

Conclusion

Across large enterprise codebases, especially those with long-lived C++ and .NET systems, the difference between theoretical and practical continuous testing becomes clear. Teams succeed when their tools allow them to isolate code reliably, keep tests fast, and maintain trust in results even as architecture evolves.

In 2026, continuous unit testing is less about running more tests and more about maintaining fast, reliable feedback as software changes. When tests are stable, isolated, and executed continuously, teams can refactor with confidence, integrate new code safely, and sustain development speed without sacrificing quality.

For modern code projects, continuous unit testing is no longer optional, it is a fundamental part of building reliable software.

Editor’s note

A version of this article was also published on CodeProject as part of an industry discussion on modern unit testing practices.

Download: Isolator++ (C++ mocking framework) 

Download: Isolator (dotnet mocking framework) 
https://www.typemock.com/download-isolator/

The post Continuous Unit Testing in 2026 appeared first on Typemock.

In this part of the Typemock Architecture series, we’ll explain, at a high level, how Isolator++ makes mocking the unmockable possible in C++ and why the v5 engine is built for modern CI, Linux, and real-world codebases.

What makes C++ mocking fundamentally hard

Most C++ mocking tools assume you designed for testability (interfaces everywhere, dependency injection, wrappers, link-time tricks). But production C++ rarely looks like that:

• Global/static functions with side effects
• Third-party libraries you can’t change
• Legacy code with tight coupling
• Complex call stacks and exceptions
• Multi-threaded test runs in CI

So the core question becomes:
How do you isolate behavior without rewriting production code?

The Isolator++ approach: intercept at runtime

Isolator++ doesn’t depend on “nice architecture.” It operates at runtime, at the level where the compiled code actually runs.

That means:

• No forced interfaces
• No source rewriting
• No “just refactor it” requirement
• The interception is active only during test execution

✅ Typemock is built for teams shipping real C++ code, not textbook examples.

How the Typemock C++ mocking framework works at runtime

Test runner starts the test process

• Isolator++ loads into the test process
• A configured call is intercepted
• The engine chooses: Return, DoInstead, or CallOriginal
• Test finishes and the process exits (no persistent hooks)

Nothing is modified on disk.
Nothing remains after the test process exits.

Why “just refactor it” often isn’t realistic in C/C++

When someone says “Just remove statics” or “Make it virtual so you can mock it”, they’re assuming you own the design and can safely change it. In real systems, that’s often false, and in C++ it can be painfully expensive or dangerous.

1) ABI and binary compatibility

Turning a non-virtual method into a virtual one can change the object layout (vtable pointer, layout/order of members), which can break:

• binary compatibility across DLLs/shared libraries
• plugins loaded at runtime
• third-party components compiled against older headers

Even “small” changes can trigger crashes that only appear in production configurations.

2) You don’t control the code

A huge chunk of static/non-virtual calls come from:

• third-party libraries
• legacy internal libraries used by multiple products
• OS APIs / vendor SDKs
  You can’t refactor them, and wrapping them everywhere is time-consuming and brittle.

3) Wide blast radius (static calls are everywhere)

Static calls often end up scattered across the codebase:

// spread across hundreds of call sites
auto path = Config::GetInstallPath();
Logger::Write("start");
auto h = File::Open(path);

Refactoring this to DI means touching many files, changing many constructors, and creating a long migration period where everything is half-old / half-new.

4) Inlining, headers, and templates amplify the pain

In C++, many non-virtual functions are:

• inline in headers
• template-based
• compiled into multiple translation units

Refactoring becomes a full rebuild, linker debugging, and performance risk, not a small change.

5) Behavioral risk: statics often hide state

Statics may include:

• caches
• singletons
• global configuration
• lazy initialization
• hidden threading constraints

Changing them can introduce subtle race conditions or initialization-order bugs.

6) Performance and determinism requirements

Some systems avoid virtual dispatch intentionally:

• Low-latency trading
• Realtime or embedded systems
• Allocation-free or deterministic code paths

Adding abstraction layers (interfaces, heap-injected dependencies) can violate performance budgets or memory constraints.

Before and after: what refactoring really looks like

Before (typical legacy)

int PaymentService::Charge(int userId) {
    auto token = Config::GetToken();          // static
    auto ok    = Gateway::Charge(token);      // non-virtual/3rd-party
    Logger::Write(ok ? "OK" : "FAIL");        // static/global
    return ok ? 0 : 1;
}

The refactor you’re being asked to do

struct IConfig { virtual std::string GetToken() = 0; };
struct IGateway { virtual bool Charge(const std::string&) = 0; };
struct ILogger { virtual void Write(const std::string&) = 0; };

class PaymentService {
public:
  PaymentService(IConfig& c, IGateway& g, ILogger& l)
    : cfg(c), gw(g), log(l) {}

  int Charge(int userId) {
    auto token = cfg.GetToken();
    auto ok = gw.Charge(token);
    log.Write(ok ? "OK" : "FAIL");
    return ok ? 0 : 1;
  }
private:
  IConfig& cfg; IGateway& gw; ILogger& log;
};

This is “clean” – but it’s also a lot of change, and sometimes it breaks ABI, performance, or release timelines.

What Typemock enables because of this reality

This is exactly why Typemock Isolator++ exists:

✅ You can unit test now, even when the code is not refactor-friendly.
✅ You can isolate static/global/non-virtual behavior without redesigning your system first.
✅ You can refactor later when it’s safe, not because a testing tool forced you into it.

The trampoline engine (high-level)

At the heart of Isolator++ is a “redirect and decide” mechanism often described as a trampoline:

1. Execution reaches a function you want to fake
2. The engine redirects control to a safe handler
3. The handler decides what to do
4. Execution returns to the test (or to the original function)

This design is what enables:

• Mocking global/static/free functions
• Intercepting calls across module boundaries
• Handling hard-to-test dependencies without rewriting

Why v5 matters: Windown, Linux, GCC and safer unwinding

Modern C++ teams run CI on Linux, across compilers, with lots of parallelism. Isolator++ v5 is designed for that environment:

• Windows Support (VS 15 and above)
• Linux support (GCC 5.4 and above)
• Modern API (C++14 baseline)

C++ mocking framework examples: from unmockable to mockable

Example 1: Mocking a static method

Production code (unchanged):

int PaymentService::Charge(int userId)
{
    auto token = Config::GetToken();     // static
    return Gateway::Charge(token);       // non-virtual / third-party
}

Test using Isolator++:

TEST(PaymentServiceTests, Charge_Succeeds)
{
    auto a = Isolate();
    a.CallTo(Config::GetToken()).WillReturnFake();
    a.CallTo(Gateway::Charge(A::Any()).WillReturn(10);

    PaymentService svc;
    bool result = svc.Charge(42);

    ASSERT_EQ(10, result);
}

No interfaces.
No wrappers.
No refactor required.

Example 2: Mocking a global / free function

bool SendPacket(const char* payload);

TEST(NetworkTests, PacketFailureHandled)
{
    auto a = Isolate();
    a.CallTo(SendPacket(A:Any())).WillReturn(false);

    auto ok = ProcessNetwork();

    ASSERT_FALSE(ok);
}

This works even if

SendPacket

Example 3: Replacing behavior with WillDoInstead

a.CallTo(SendPacket(nullptr)).
    .WillDoInstead([](const char* payload) {
        return strlen(payload) < 1024;
    });

This is extremely powerful for:

• simulating failures
• edge cases
• complex behaviors
• time-dependent or flaky dependencies

Where this fits in the full Typemock architecture

Isolator++ is one layer in the broader Typemock system:

• Mocking / Isolation engine (this post)
• SmartRunner (impact-based test running)
• Coverage (instant coverage + reporting)
• Deep IDE integration (especially Visual Studio)

This is what allows a team to go from “we can’t unit test this” to “tests run fast, in isolation, continuously.”

Test frameworks commonly used with a C++ mocking framework

Most teams using a C++ mocking framework like Typemock run their tests through standard, well-known test runners:

• GoogleTest (gtest) — a widely used C++ unit testing framework for writing and running tests.
  https://github.com/google/googletest
• CTest — CMake’s test driver, commonly used in CI pipelines to execute C++ test suites.
  https://cmake.org/cmake/help/latest/manual/ctest.1.html
• Microsoft Test Platform (VSTest / MSTest) — the test platform used by Visual Studio and Azure DevOps pipelines, commonly running native C++ tests on Windows.
  https://learn.microsoft.com/en-us/dotnet/core/testing/

Typemock Isolator++ works with all of these runners, loading only inside the test process and acting as a C++ mocking framework at runtime without requiring changes to production code.

Next in the series

Part 4: coming soon (what changes the economics of unit testing).
Part 1: How the .NET Isolation Engine works
Part 2: Inside the .NET Isolator Engine

Download: Isolator++ (C++ mocking framework trial)

The post C/C++ Mocking Framework Architecture: Typemock Isolator++ (Part 3) appeared first on Typemock.

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:

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

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:

Isolate.WhenCalled(() => File.ReadAllText("settings.json"))
       .WillReturn("fake-config");

Or:

Isolate.Fake.StaticMethods(typeof(LegacyManager));

Or even:

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

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

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/

The post ⭐ Typemock Architecture: Inside the .NET Isolator Engine (Part 2) appeared first on Typemock.

Every development team evaluating Typemock eventually asks the same thing:
“What is the actual Typemock architecture, and how does it pull off impossible mocking?”

Developers don’t normally believe in magic.
We believe in compilers, debuggers, and well-defined runtime behavior.
So when Typemock first fakes a static method, or overrides a sealed class, or stubs out a private constructor without requiring a single code change most .NET developers react the same way:

“How is this even possible?”

It feels like a small glitch in reality.

But behind that moment of magic is something far more practical
a deep, carefully engineered architecture designed to give developers one thing traditional unit-testing workflows rarely allow:

Freedom.

Freedom to test real systems without reshaping them.
Freedom to avoid unnecessary abstractions and artificial seams.
Freedom to keep your code clean not “testable by design,” but simply designed well, while Typemock handles the complexity.

Most mocking tools tell you: “You can test this code… but only if you rewrite it to fit my rules.”

Typemock was built for the opposite: You test the code you have designed for perfection .

In this post, we’ll walk through the actual architecture that makes Typemock’s “impossible mocking” not only possible but stable, predictable, and enterprise-ready.

This is a technical deep dive but one written for humans.
Whether you’re a developer, architect, DevOps lead, or InfoSec reviewer, this will give you a clear understanding of:

• What Typemock installs
• How it integrates with Visual Studio
• How it works with .NET test runners
• How the core Isolator Engine operates under the hood
• Why it can mock things other frameworks cannot
• Why this approach is safe, local, and doesn’t modify code on disk

🌱 The Difference in One Glance: A Standard Mock vs. a Typemock Mock

Sometimes the best way to understand the freedom Typemock gives developers is to look at the code.

Here’s how mocking usually looks with traditional frameworks:

❌ “Standard” Mock (Clunky, Wrapper-Heavy, Refactor-Dependent)

// Forced to create interface just for testing
public interface IFileReader
{
    string Read();
}

public class FileReader : IFileReader
{
    public string Read() => File.ReadAllText("config.json");
}

// Test using DI + wrapper pattern
[Test]
public void Reads_Config()
{
    var fake = new Mock<IFileReader>();
    fake.Setup(r => r.Read()).Returns("demo-data");

    var sut = new Service(fake.Object);
    Assert.AreEqual("demo-data", sut.Load());
}

You had to:

• Rewrite production code
• Introduce an interface
• Wrap static file access
• Change constructor signatures

All just to test a simple line.

✅ Typemock Mock (Clean, Direct, No Refactoring)

[Test]
public void Reads_Config()
{
    Isolate.WhenCalled(() => File.ReadAllText("config.json"))
           .WillReturn("demo-data");

    var sut = new Service();
    Assert.AreEqual("demo-data", sut.Load());
}

No interfaces.
No wrappers.
No dependency injection.
No architecture changes.

Just the test — as it should be.

This is the heart of the Typemock architecture:
freedom to test without rewriting your world.
Let’s start at the top.

🧱 1. The Typemock Mental Model. Three Clear Layers

Before diving deep, it helps to have a mental map:

1. Visual Studio Layer (Interaction)

UI, menus, test runner integration, SmartRunner, Suggest, Coverage visualization.

2. Test Runner Layer (Execution)

Your usual runner:

dotnet test

3. Isolator Engine Layer (Interception)

The runtime engine that loads inside the test process and manipulates execution.

These layers are completely separated.
This is the first reason Typemock is stable and safe:

Visual Studio shows the UI.
The test runner executes tests.
The Isolator Engine rewrites behavior only in memory.

🧩 2. Desktop Installation: Simple, Contained, and Transparent

On Windows, Typemock installs only the essentials:

✔ Typemock Isolator Engine (.NET runtime interception engine)

This is the core runtime library.

✔ Visual Studio Extension

Adds Typemock menus, toolbars, windows, and integration with test workflows.

✔ CLI + Runner Helpers

Used for

dotnet test

That’s it.

There are no:

❌ background services
❌ permanent processes
❌ kernel drivers
❌ system hooks
❌ global monitors

Once installed, nothing runs unless you run tests.

Many enterprise customers appreciate this clean footprint immediately, InfoSec teams even more so.

🚀 Experience the Freedom of the Typemock Architecture

Want to see this architecture in action statics, sealed, privates, legacy code – all mocked cleanly, without refactoring?

👉 Download the free trial and experience the Isolator Engine yourself:
https://www.typemock.com/download-isolator/

🎛️ 3. Visual Studio Integration, Your Daily Surface Area

Typemock’s VS extension exists to make the developer workflow smooth, not magical.

Inside Visual Studio, you get:

🔧 Deep Integration

• Typemock menus
• Test windows
• Shortcuts
• Quick actions
• Code lenses (did we invent that – ye!)
• Test explorers

💡 Suggest (AI Test Suggestions)

Analyzes your code and suggests possible unit tests.
Especially useful for legacy codebases or unfamiliar code paths.

⚡ SmartRunner (Impact-Based Test Running)

Tracks your edits → identifies which tests are affected → runs only those tests.

SmartRunner feels like a quality-of-life feature…
Until the first time you save 30 minutes on a solution with 6,000 tests.

📊 Coverage Visualization

Shows which lines of code are covered directly inside the editor.

This keeps your workflow productive and clean, but it does not execute the tests or perform mocking.

That responsibility belongs to…

🧠 4. The Isolator Engine: How We Intercept Without rewriting, Where the Magic Actually Happens

This is the heart of the entire system.

The Patented Typemock Isolator Engine integrates deeply into the .NET runtime using the CLR Profiler API, which gives it visibility into:

• Method JIT compilation
• Type loading
• IL rewriting
• Execution flow
• Call dispatching

✔ Interception at JIT Time

When your test runner starts a test, the CLR begins to JIT methods.
Typemock intercepts these methods before they are turned into machine code.

This gives Typemock a rare ability:

It can rewrite method behavior in memory before .NET executes it.

This is the core mechanism behind:

• Mocking statics
• Mocking sealed classes
• Mocking private or internal methods
• Redirecting constructor calls
• Mocking legacy or tightly coupled code

No source code changes.
No need to force interfaces.
No need to wrap statics.

Just runtime control.

✔ In-Memory Only — Zero Disk Changes

Everything happens in the test process, and everything goes away when the test ends.

🔄 5. Integration with .NET Runners

Typemock works with:

• VSTest
• dotnet test
• xUnit
• NUnit
• MSTest
• ReSharper Test Runner
• Rider (via VSTest integration)

To learn more about standard .NET testing infrastructure, see Microsoft’s documentation here:
https://learn.microsoft.com/en-us/dotnet/core/testing/

Let’s walk through the real process – transparently.

1️⃣ You run tests almost normally:

• TMockRunner.exe

• dotnet test

• Visual Studio Test Explorer
• NUnit/xUnit consoles

2️⃣ A test process is launched

(e.g.,

testhost.exe

3️⃣ Typemock Isolator Engine loads into THAT process

Not Visual Studio.
Not your OS.
Only the test process.

4️⃣ CLR begins JIT compilation

Typemock intercepts the JIT pipeline.

5️⃣ The engine rewrites execution paths in memory

It replaces real behavior with mocks/fakes.

6️⃣ Tests run with full control

Statics, privates, sealed classes — all mockable.

7️⃣ Process exits → Engine disappears

No residue.
No permanent modifications.
Perfect isolation.

Simple, safe, contained.

⛓️ 6. Why Typemock Succeeds Where Other Mocking Tools Fail

Most traditional .NET mocking frameworks rely on:

• Reflection
• Dependency injection
• Virtual methods
• Interfaces
• Dynamic proxies
• Constructor injection
• Lightweight rewrite layers

This makes them good for clean code, but almost useless for:

• Legacy systems
• Static-heavy codebases
• Code you cannot modify
• Deeply nested frameworks
• Third-party SDKs
• Uncooperative architectures

Typemock bypasses these restrictions because it operates at the runtime level, not the language/API level.

The moment developers realize this, they understand the “impossible mocking” reputation.

🛡️ 7. Why InfoSec and DevOps Teams Approve This Architecture

Typemock is often evaluated inside large enterprises with strict rules.

Here’s why they approve it:

✔ No global footprint

No services, no daemons, nothing resident.

✔ No modification to source

No trace left in the codebase.

✔ No assemblies rewritten

Everything is runtime-only.

✔ Clean install/uninstall

No registry spam or system hooks.

✔ Reproducible behavior

Visual Studio → CLI → CI — always identical.

✔ Clear boundaries

Engine only runs inside the test process.

✔ Works without admin rights

No privileged operations needed.

This architecture was designed specifically to make Typemock safe, predictable, and stable for enterprise-scale development.

🎯 8. Summary: The Architecture Behind the Magic

Typemock is not a trick.
It is not a hack.
It is not a workaround.

It is a deeply engineered .NET runtime integration that:

• Intercepts method calls at JIT time
• Rewrites behavior in memory
• Loads only inside test processes
• Leaves code and binaries untouched
• Works with any runner
• Integrates seamlessly with Visual Studio
• Makes mocking the “impossible” not just possible – but easy

This is why Typemock is used in:

• Banking
• Aviation
• Healthcare
• Gaming
• Defense
• Enterprise SaaS
• Large legacy modernization projects

Because it gives teams the one thing most mocking tools cannot:

Freedom.
Freedom to test without rewriting the world.

🎯 Experience the Freedom. Download the Isolator Engine.

The Typemock architecture is built for real teams, real complexity, and real systems — not toy examples.

If you want to:

• Break free from wrapper hell
• Stop redesigning code just to test it
• Test legacy systems from day one
• Get instant feedback with SmartRunner
• Keep your CI fast and predictable

Then you’re ready to experience what deep runtime integration feels like.

👉 Try Typemock on your codebase today

Download the free trial

The post ⭐ Typemock Architecture: How the .NET Isolation Engine Works Under the Hood appeared first on Typemock.

Typemock Isolator 9.4 is here built to keep your team ahead as the .NET ecosystem accelerates.
This release focuses on platform compatibility, developer experience, and test-runner stability, with deep updates to our core, SmartRunner and our installer.

Whether you’re testing complex legacy systems or pushing into .NET 10 and Visual Studio 2026 Insiders, this update makes your workflow smoother, faster, and more predictable.

💡 What’s New in Typemock Isolator 9.4

✅ Ready for .NET 10 and Visual Studio 2026

We now support the newest runtimes and IDEs:

• .NET 10
• Visual Studio 2026 Insiders
• VSTest 4

This means you can upgrade your development environment without breaking your test suite.

# Installing the latest version
Install-Package Typemock.Isolator -Version 9.4.0

⚡ SmartRunner Now Adapts Automatically to Your Project Runtime

SmartRunner now runs under the same .NET runtime as your test project.

Why this matters

Previously, mismatched runtimes could cause inconsistent behavior especially in multi-TFM solutions.
Now SmartRunner aligns itself automatically:

• No manual configuration
• No unexpected x86 launches
• No runtime mismatch errors

This significantly improves test reliability.

<PropertyGroup>
   <TargetFramework>net8.0</TargetFramework>
</PropertyGroup>

<!-- SmartRunner automatically uses net8.0 too -->

🛠️ Better Architecture Selection (Auto/x86/x64)

We’ve upgraded the Auto mode to make smarter decisions when choosing the architecture at runtime.
This eliminates cases where SmartRunner unnecessarily launched as x86.

Result: fewer edge-case failures and more predictable behavior in mixed architecture environments.

📦 Cleaner Installer & Uninstall Flow

A major theme in this release is predictability.

We improved:

• Full cleanup of all directories on uninstall
• More reliable detection of Visual Studio 2026 installations
• Better fallback behavior when probing for components
• Improved help/documentation build pipeline

If you’ve ever managed enterprise rollouts of extensions, you’ll feel the difference immediately.

📚 Documentation & Examples Improved

We updated:

• Example projects (cleaner, simplified, coverage-ready)
• Help docs (alignment fixes)

🔧 Stability Fixes Across the Board

Isolator 9.4 includes targeted fixes in SmartRunner, the installer, and the Visual Studio extension.

Key fixes:

• SmartRunner no longer restarts after build
• SmartRunner stops correctly when build fails
• Logging disabled = logging truly disabled
• Removed old

  Marshal.ReleaseComObject

  code
• Fixed null-reference issues in several edge cases
• Fixed VS extension images
• Fixed .NET x86 runtime selection confusion
• Core runner logs no longer always emitted

This release reflects weeks of internal testing across multiple TFMs and architectures.

📦 NuGet Package Improvements

This version includes a fully modernized NuGet package structure:

• README displayed directly in NuGet
• Embedded icon
• License file included
• TFMs updated (net45, net6.0, net8.0, net10.0)
• Cleaner dependency groups

We also simplified TFM mappings so all modern .NET versions share a consistent dependency set.

🚀 Start Testing Smarter Today

Typemock Isolator 9.4 is available now:

👉 Download: https://www.typemock.com/download-isolator
👉 NuGet: https://www.nuget.org/packages/Typemock.Isolator
👉 Docs: https://www.typemock.com/docs

Whether you’re maintaining a massive legacy system or building tomorrow’s .NET applications, Isolator continues to be the most powerful mocking framework ever created.

The post Introducing Typemock Isolator 9.4 appeared first on Typemock.

🚧 The Problem Every Developer Knows

“You can’t mock statics.”
“You can’t test private methods.”
“You have to refactor first.”

Every .NET developer has heard it.
You hit a wall: a static class buried deep in legacy code, a private call controlling your logic, and a testing framework that just shrugs.

This is the story of how we made mocking statics in .NET possible, and why it changed everything.

public static class LicenseChecker
{
    public static bool IsValid()
    {
        return ExternalService.Ping();
    }
}

You can’t replace that call.
You can’t fake it.
You can’t test it – not without rewriting half your system.

Except… you can.

⚡ The Breakthrough in Mocking Statics in .NET

When Typemock started, we wanted to do something outrageous — mock what everyone said was unmockable.
We didn’t want developers to be punished for using statics or privates.
We wanted testing freedom.

So we did what every great engineer does when told “you can’t.”
We found a way.

Isolate.WhenCalled(() => LicenseChecker.IsValid())
       .WillReturn(true);

One line.
The static vanished.
Your test took control.

🧠 How It Works

Most mocking frameworks take the “safe” route. They force you to change your software to make it testable.

You add interfaces.
You create wrappers.
You invent abstraction layers that exist only for the sake of testing.
You manage endless versions of the same logic.

On paper, it looks clean. In practice, it’s fragile, complex, and full of mental overhead.
Every new developer has to understand a maze of fakes and indirections before they can even read your code.

That’s not engineering — that’s bureaucracy.

Complexity is not control.
Simplicity is.

Typemock took the opposite approach.
We intercept the actual method calls inside the CLR – not through proxies, not through code generation, but through direct runtime interception.

Instead of rewriting your code to make it testable, Typemock lets your code stay simple and still be fully testable.
That’s the power behind mocking statics in .NET without refactoring

This innovation was so novel it was granted a U.S. Patent for its design – recognizing it as a new kind of runtime interception technology.

The result?
Tests that respect your design instead of dictating it.
Fewer abstractions. Fewer layers. More clarity.
The simplicity that makes great software readable and great tests possible.

🔍 Why It Still Matters

Most frameworks evolve around language features.
Typemock evolved around developer intent – the belief that you should test any code you own, even if it was written years ago, by someone else, under impossible constraints.

That’s why the same engine that once shocked .NET developers now powers AI-assisted test generation, Insights visualization, and deterministic test execution – all still built on that original, impossible idea.

We didn’t just make testing faster.
We made it simpler.

💡 Try It Yourself

Stop rewriting code just to test it.
Experience the freedom that started it all.

👉 Download Typemock Isolator Free

No wrappers. No refactoring. Just control.

The post Mocking Statics in .NET – We Made the Impossible Possible appeared first on Typemock.

Best Practices for .NET & C++ Developers

Why This Matters

Mocking is a superpower in modern unit testing, but like any power, it can be overused.
Used wisely, mocks make tests lightning-fast and clean. Used recklessly, they create an illusion of stability while real bugs hide in production.

In this post, we’ll explore when to use mocking in unit testing, when it hurts, and how to build a healthy test suite that blends both isolation and reality.

👉 Haven’t read our intro yet? Start with Learn the basics of mocking before diving deeper

When to Use Mocking in Unit Testing

Mocking shines when your code interacts with anything outside your control:

• External APIs or microservices
• File systems, databases, or queues
• Time, randomness, or system state
• Legacy dependencies that are expensive or slow to instantiate

Mocks give you deterministic, isolated, repeatable tests – perfect for agile teams and CI pipelines.

Example (.NET / MSTest)

[TestMethod]
public void Should_Send_Notification_Without_Hitting_Real_Service()
{
    var email = Isolate.Fake.Instance<IEmailService>();
    Isolate.WhenCalled(() => email.Send("dev@typemock.com"))
           .WillReturn(true);

    var notifier = new Notifier(email);
    Assert.IsTrue(notifier.Notify("dev@typemock.com"));
}

This test runs instantly, without any real email traffic.
You’ve isolated the logic that matters and ignored the infrastructure that doesn’t.

Example (C++ / Isolator++)

TEST(Legacy, Should_Process_Data_Without_Hitting_Database)
{
    Isolator a;
    auto db = a.Fake.Instance<IDatabase>();

    a.CallTo(db->SaveRecord()).WillReturn(true);

    DataProcessor processor{db};
    ASSERT_TRUE(processor.Process());
}

Here the fake database mimics expected behavior, letting you verify logic without connecting to the real DB.

When Not to Mock

If everything in your system is mocked, you’re not testing reality, you’re just validating assumptions.
Mocks hide bugs when used in integration scenarios.

Avoid mocks when:

• You’re testing data integrity or schema mapping
• You need to verify serialization, configuration, or endpoints
• You’re testing framework behavior (Entity Framework, gRPC, etc.)
• You’re writing integration or end-to-end tests

⚠️ Over-mocking leads to “green builds” that fail in production.

The Rule of Three

A simple way to decide whether to mock:

1. Is it slow? → Mock it.
2. Is it external? → Mock it.
3. Is it internal and stable? → Test it directly.

This keeps your suite fast without faking the world.

Best Practices for When to Use Mocking in Unit Testing

✅ Keep one fake per test.
✅ Name fakes clearly (

fakeGateway

mockRepo

WillDoInstead()

Use Isolator Insights to Visualize Your Mocks

Even with the best practices above, it can be hard to see what’s really happening inside your tests.
That’s where Typemock Isolator Insights comes in.

Insights gives you a real-time view of:

• Which methods and objects were faked
• How your mocks interact during test execution
• Where setup or verification might be missing

You can instantly trace your test flow, verify mock behavior, and debug unexpected calls, all without adding extra logging.

💡 Use Insights whenever a test fails or behaves unexpectedly. It helps you confirm whether your mocks are configured correctly or if the issue lies in your real code.

How Typemock Helps

Most frameworks stop where your real problems start – sealed, static, or private methods, or deep legacy C++ code.
That’s where Typemock excels.

• Typemock Isolator for .NET lets you fake anything – no refactoring required.
• Isolator++ for C++ isolates legacy code and static functions with a simple, modern API.
• Both integrate smoothly with your CI and test frameworks.

👉 Download Isolator++ Free or Isolator dotNet and start testing the untestable.

Frequently Asked Questions

Conclusion

Mocking isn’t about avoiding the real world – it’s about controlling it while you verify your logic.
A balanced testing strategy combines mock-based unit tests with selective integration tests, keeping your builds fast and reliable.

Use mocks wisely, and your tests will be your safety net – not your blindfold.

💡 Next: Learn the basics of mocking learn the basics behind mocks, fakes, and stubs.
You can also read Martin Fowler’s classic post on Mocks Aren’t Stubs for deeper context.

The post When to Use Mocking in Unit Testing (.NET & C++) appeared first on Typemock.

Isolator 9.3.7 for .NET

New: Added license unregistration support for Azure dynamic agents via both

TMockRunner.exe

This update makes it easier to manage Typemock licenses in cloud-based build environments, where agents are automatically provisioned and released.
When Build Licenses need to transfer between dynamic agents, Isolator now handles it smoothly — ideal for teams scaling test execution dynamically in Azure Pipelines.

Isolator++ 5.4 release for C++

A major release introducing new API capabilities, expanded Linux support, and more flexible mocking control.

🔹 New API Linux Support

Now supports Clang (minimum Clang 10) and C++14 (Enterprise License only) — broadening platform reach for Linux developers using Typemock.

🔹 Control and Verify Future Constructors

You can now control and verify future constructor calls — a powerful feature for complex object creation chains.

TEST(EnterpriseExamples, FutureCtor_VerifyBaseConstructorCalled)
{
    // Arrange
    auto a = Isolator();
    auto handle = a.Fake.All<SecretGPSLocation>(FakeOptions::CallOriginal);

    // Act
    auto derived = new SecretGPSLocation();

    // Assert
    // Verify base (GPSLocation) ctor was invoked with any arguments
    a.CallToPrivate(A::Ctor<GPSLocation>(handle), A::Any(), A::Any()).VerifyWasCalled();
}

🔹 During Filters — Conditional Fakes

You can now limit fakes to specific runtime conditions using During Filters.
This gives developers precise control, letting you fake behaviors only when they occur within certain modules or scopes.

TEST_F(ConditionalBehavior, MultipleDuringFiltersUsingAModuleSucceeded)
{
    auto a = Isolator();
    auto fake = a.Fake.Instance<Person>();

    // Restrict fakes to GetName called within Test.dll
    a.CallTo(fake->GetName()).During(A::Module("Test.dll")).WillReturn("John");

    auto res = fake->GetName();
    ASSERT_TRUE(strcmp(res, "John") == 0);
}

🔧 Summary of What’s New

DotNet: Isolator 9.3.7

• License unregistration support for Azure dynamic agents
• Available through

  TMockRunner.exe

  and Azure DevOps Tasks

C/C++: Isolator++ 5.4.0

Isolator++ 5.4 release continues Typemock’s mission to simplify testing for C++ developers across Windows and Linux.

• Clang (v10+) and Linux C++14 support
• Future constructor verification
• “During Filters” for conditional mocking

👉 Download the latest version now:
Download Isolator
Download Isolator++

Read more:
Azure DevOps Documentation
Clang Compiler Overview

The post Typemock October Release: Isolator 9.3.7 and Isolator++ 5.4.0 appeared first on Typemock.