Understanding Why Overly Aggressive Mocks Break Later in Software Testing
By
ingve
Crisp on the outside, thoughtful on the inside. A keeper.
Summary
The article explains why overly aggressive mocking in software testing can appear to work initially but break later. It discusses the rule of mocking where objects are used rather than where they're defined, and how violating this rule can lead to tests that pass temporarily but fail when code changes or when tests are run in different environments. The author uses code examples to illustrate how mocks that are too specific can create fragile tests that break unexpectedly.
Key quotes
· 4 pulledMock where the object is used, not where it's defined.
An overly aggressive mock can work fine, but then break much later.
The test will only pass if you create the correct settings.json file in the right location.
In some cases, the mock will work even if you don't follow this rule, and then it can break much later.
You might also wanna read
Managing Test Fixture Dependencies in Large Software Projects
The article discusses the problem of 'frozen test fixtures' in large software projects, where test fixtures become difficult to modify becau
radanskoric.com·5mo ago
Why Average LLM Use Is Likely Destroying Value in Software Development
The author argues that, contrary to prevailing hype, the average use of Large Language Models (LLMs) is likely destroying value rather than
unessays.substack.com·10h ago
How AI Accelerated Prototyping: From Idea to Tangible in Record Time
The author reflects on how AI has transformed their prototyping workflow. Previously, the biggest bottleneck was the time needed to scaffold
darylcecile.net·10h ago
GitLab 19.0 launches with Secrets Manager, agentic workflows, and self-hosted AI models
GitLab 19.0 has been released, positioning itself as an intelligent orchestration platform for DevSecOps. The release includes expanded secr
bit.ly·23h ago
Centralizing Error Handling in Rust with Custom AppError Enums
This article discusses the importance of centralizing error handling in Rust applications using a custom AppError enum combined with map_err
Zig Devlog: Build System Rework Separates Maker and Configurer Processes
This devlog entry from the Zig programming language project announces a major rework of the build system, separating the maker process from
ziglang.org·1d ago