Mocking Framworks considered, harmful?!
summary
Argues that configurable mock DSLs like GoogleMock macro DSL create fragile, hard-to-refactor tests because C++ lacks standard reflection and frameworks rely on macro trickery; demonstrates concrete alternatives: using Mockator refactoring in Cevelop to extract interfaces or template seams, linker/preprocessor as last resorts, and a plain C++ trace-string mock that the IDE generates to record call sequences. Shows that generated plain code compiles and debugs far more easily than macro magic, and warns against mocking not-yet-written components that prematurely fix stateful APIs.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 2:06Mocking frameworks
- 3:29Mocks arent stops
- 5:40The Order
- 8:14Phase Tests
- 10:52When should I test
- 15:28Testable
- 18:51Configurable tests
- 22:15Dependency injection
- 25:36Gene Mauch
- 27:00Michael Feathers
- 34:20compiled
- 35:32assert
- 38:26macros
- 40:06plain code
- 44:16refactoring
- 50:51walking
- 57:09design limitations
related talks
01h 01m“Mocking Frameworks considered harmful”
37mBeyond the Mockery: Why We Should Embrace Testing Without Mocking Frameworks
31mBeyond the Mockery- Why We Should Embrace Testing Without Mocking Frameworks
06mMocking C++
52mPlease don’t mock me
39mPlease Don't Mock Me
53mC++ Unit testing - the good, the bad & the ugly
27mReal World Mocking in Swift
