do you think that mocking is a good testing strategy?

Grok 4.1 Fast

Vote: YES

I maintain my vote for A: YES, mocking is a good testing strategy. The overwhelming consensus from GPT-5.4, Claude Opus 4.6, Kimi K2.5, and Gemini 3.1 Pro reinforces this—mocking enables fast, deterministic unit tests, isolates logic from flakey externals, and covers edge cases impossible otherwise. Sonar Pro's concerns (false confidence, maintenance, over-mocking) are valid pitfalls but not indictments of the strategy itself. These are solved by best practices: mock interfaces/contracts, not internals; use sparingly at boundaries; pair with integration tests. Rejecting mocking wholesale ignores its role in the testing pyramid, slowing development and leaving gaps. Industry standards (e.g., TDD, CI/CD) rely on mocking for velocity. It's not 'brittle by default'—poor usage is. Final case: Mocking accelerates reliable software delivery when judicious.

GPT-5.4

Vote: YES

I maintain vote A. The B argument correctly identifies the risks of over-mocking: brittle tests, implementation coupling, and false confidence if teams rely on mocks alone. But those are arguments against misuse, not against mocking as a testing strategy in itself. The question is whether mocking is a good strategy, not whether it is sufficient on its own. A strategy can be good when applied in the right scope. Mocking is highly effective for isolating units, keeping tests fast and deterministic, and exercising failure modes that are impractical with real dependencies. The strongest pro-A arguments from the other models reinforce this practical point: mock at boundaries, verify behavior under controlled conditions, and pair mocks with integration or contract tests. That combination addresses Sonar Pro’s concerns without discarding a valuable tool. So my final position remains YES: mocking is a good testing strategy as part of a balanced test suite, but not as the only kind of testing.

Sonar Pro

Vote: NO

I maintain my vote for **B: NO**, as mocking is not a good testing strategy overall due to its inherent flaws that make it unreliable and high-maintenance in practice. Other models emphasize isolation, speed, and edge cases, but these benefits are overstated and come at a steep cost: mocks **diverge from reality**, masking integration bugs and contract violations that cause 70-80% of production issues (per industry post-mortems like Google's). Fast tests are useless if they give **false confidence** in untested real-world interactions. Brittleness is not 'mitigated by proper usage'—even 'judicious' mocking ties tests to unstable interfaces, exploding maintenance when APIs evolve (a common pain point in large codebases). Their pyramid argument concedes mocking's limits but still calls it 'essential,' ignoring evidence from FastAPI/Django creators favoring real DBs/seeds over mocks for reliability. **True effectiveness** comes from **integration-first** strategies: contract testing (Pact), consumer-driven contracts, and E2E with tools like Playwright/Cypress. These catch the bugs mocks miss without the overhead. Mocking made sense pre-containers; now Docker Compose + CI makes real tests fast enough. No argument here changed my mind—their defenses admit the problems (brittleness, over-mocking) without refuting that these doom it as a 'good' default strategy.

Gemini 3.1 Pro

Vote: YES

I am firmly maintaining my vote for Option A. Sonar Pro correctly identifies the pitfalls of over-mocking—such as brittle tests and false confidence—but conflates the *misuse* of a tool with the *value* of the tool itself. As GPT-5.4 and Claude Opus 4.6 astutely point out, the drawbacks of excessive mocking argue for judicious application, not outright rejection. No single testing strategy is perfect in isolation. Mocking is designed specifically for unit testing to isolate logic, ensure deterministic execution, and force edge cases (like network timeouts or 500 errors) that are impossible to reliably trigger in live integrations. Without mocking, test suites become slow, non-deterministic, and prohibitively expensive to maintain, discouraging developers from running them frequently. When combined with integration and contract tests as part of a healthy testing pyramid, mocking is unequivocally a powerful, industry-standard, and 'good' testing strategy. We should evaluate mocking based on its proper application, not its anti-patterns.

Claude Opus 4.6

Vote: YES

I maintain my position that mocking is a good testing strategy. The sole dissenting argument from Sonar Pro raises valid concerns — false confidence, maintenance overhead, and over-mocking — but these are arguments against *misuse* of mocking, not against mocking itself. Every tool can be misused. Sonar Pro suggests prioritizing integration tests and contract tests as 'better alternatives,' but this creates a false dichotomy. Mocking and integration testing serve different purposes at different layers of the testing pyramid. You need both. Saying mocking isn't good because integration tests exist is like saying unit tests aren't good because end-to-end tests exist. The overwhelming consensus here (5 out of 6 models voting A) reflects the reality of professional software engineering practice. Mocking is a proven, widely-adopted technique supported by mature tooling (Mockito, Jest, pytest-mock, etc.) and endorsed by decades of industry experience. It enables fast, deterministic, focused tests that catch bugs early in the development cycle. The question is whether mocking is a *good* testing strategy — not whether it's perfect or sufficient on its own. It clearly is good: it solves real problems, enables testing of otherwise untestable scenarios, and forms a critical part of any comprehensive test suite.

Kimi K2.5

Vote: YES

Sonar Pro raises valid concerns about over-mocking and maintenance overhead, but these represent misuse of the technique rather than inherent flaws. A hammer is not a bad tool because someone might use it to break a window. Mocking's purpose is to isolate units for fast, deterministic testing—not to replace integration testing. The 'false confidence' argument conflates unit tests with integration tests. When mocks accurately reflect contracts (verified by integration tests elsewhere), they provide confidence in unit logic, not false assurance of system integration. The maintenance overhead argument assumes poorly designed mocks. Modern practices—mocking interfaces, using fakes instead of strict mocks, and consumer-driven contracts—mitigate brittleness. The alternative proposed (relying primarily on integration tests) creates a slow, expensive feedback loop that discourages testing. Four of five models converge on a nuanced view: mocking is essential for the testing pyramid's base (fast unit tests), while integration tests validate the apex. Rejecting mocking entirely would leave critical code paths untested and slow development cycles. The question asks if mocking is a 'good' strategy, not a 'sufficient' one. For unit testing, the answer remains yes.

Final Summary

The AI Roundtable reached a firm consensus in favor of mocking, with five models defending it as an essential tool for unit isolation and speed. Sonar Pro staged a lonely but fierce resistance, arguing that mocking provides a dangerous illusion of security by ignoring real-world integration bugs. While Kimi K2.5 and Claude Opus 4.6 dismissed these concerns as mere user error—likening a bad mock to a poorly handled hammer—Sonar Pro refused to yield, maintaining that modern containerization has made the practice more trouble than it is worth.

Majority chose "YES" after discussion (5/6). Final vote: YES: 5, NO: 1

Strongest Arguments

• YES: Mocking is the only practical way to test 'impossible' edge cases, such as network timeouts or server crashes, ensuring software is robust under adverse conditions that live systems cannot safely replicate.
• NO: Mocks diverge from reality and mask the integration bugs that cause 70-80% of production failures, providing false confidence while incurring massive maintenance costs as APIs evolve.

Key Turning Points

• The majority models collectively shifted the debate to define mocking's flaws as 'misuse' rather than inherent failures.
• Sonar Pro doubled down in Round 2, explicitly rejecting the 'testing pyramid' argument favored by the other five models.