Solidity's external contract mocking vs Rust's mockall crate vs Move's test-only modules

Pro: Ecosystem Maturity - Integrated with Hardhat/Foundry, enabling complex state manipulation (e.g., vm.mockCall). This matters for testing intricate DeFi integrations with protocols like Uniswap or Aave. Con: Boilerplate & Risk - Requires manual interface duplication and external mock contracts, increasing audit surface and potential for misalignment with the real dependency.

Pro: Compile-Time Safety - Generates mock implementations automatically via procedural macros, ensuring type safety. This matters for complex off-chain logic in clients or indexers (e.g., near-sdk-rs). Con: Environment Constraint - Tied to the Rust toolchain; cannot mock on-chain contracts directly. Requires a separate, non-deterministic testing environment.

Pro: First-Class Language Feature - #[test_only] functions and modules are part of the Move language spec (Aptos, Sui). This matters for ensuring deterministic, on-chain-like execution in unit tests. Con: Limited Scope - Primarily for unit-level isolation. Mocking external, non-Move dependencies or complex integration scenarios is less straightforward.

Choose Solidity Mocking for Ethereum/EVM L2s (Arbitrum, Optimism) where testing against live forked mainnet state is critical. Choose Rust/Mockall for high-assurance off-chain infrastructure (indexers, CLIs) or non-EVM chains with Rust SDKs (Solana, NEAR). Choose Move Test-Only Modules for developing native assets or DeFi protocols on Move-based chains (Aptos, Sui) where test fidelity to production is paramount.

Explicit contract deployment: Mocks are separate .sol files, providing clear separation of concerns and reusable across test suites. This is critical for protocols with complex dependency trees like Aave or Uniswap V3, where you need to simulate entire external systems (e.g., price oracles, other pools).

Manual boilerplate: Each mock requires writing and maintaining a full contract interface and implementation. This creates friction for rapid iteration and unit testing, as seen in early-stage DeFi projects where contract interfaces change frequently.

Zero-boilerplate mocking: Annotate a trait with #[automock] to auto-generate a mock with default implementations. This enables fast, granular unit testing for Solana (Anchor) or CosmWasm projects, where testing internal logic without blockchain context is essential for security audits.

Increased build times: Macro expansion and code generation can slow down compilation, a tangible cost for large monorepos like those in NEAR Protocol or Sealevel parallel runtime development. This trades developer speed for CI/CD pipeline latency.

Native, secure abstraction: #[test_only] functions and modules are stripped during compilation, preventing test code from affecting production bytecode. This is non-negotiable for high-asset protocols on Aptos or Sui, where any deployment artifact risk is unacceptable.

Constrained to module boundaries: You can only mock dependencies within the same package or via explicit test stubs. This makes it challenging to test integration with external, upgradeable system modules, a common pattern in on-chain governance or DAO frameworks.

High manual overhead: Developers must write and maintain separate mock contract files, increasing test suite size. Runtime substitution risk: Mocks are deployed addresses; accidental mainnet deployment of mock code is a real security concern (see Parity wallet hack history). This approach favors flexibility over safety.

Isolated from VM semantics: Mockall tests run in a standard Rust environment, missing the Move VM's resource semantics and global storage. This can hide bugs related to asset ownership (key/store) or cross-module interactions that only appear in an on-chain context, creating a false sense of security.

First-class, verifier-enforced testing. Modules marked #[test_only] are stripped at bytecode verification, eliminating deployment risk. They have full access to VM internals and global storage, allowing for authentic integration tests of resource handling (e.g., testing Coin transfers in Aptos Framework).

Cannot mock external dependencies in the traditional sense. You can only test against the actual published modules on-chain or create local test-only stubs. This makes it challenging to simulate failure states of external oracles (e.g., Pyth) or other chain-specific services, pushing complexity into integration test environments.