You open a test file you wrote six months ago. It takes ten minutes to figure out what the test actually verifies. The mock setup is dense, the expectations are chained, the matchers are generic. The intent is buried under the mechanics.
Most MVC PHP projects skip the Presenter. The controller fetches an entity, passes it to a template, and the template handles the rest: formatting dates, computing labels, picking CSS classes from status values. It feels pragmatic at first. It rarely stays that way.
Mocking a repository in tests does not verify your query; it only verifies that the method was called. Run a real database instead and the test suite slows to a crawl, so you run it less often. Either way, your filter logic ends up duplicated: once in the production code that hits the database, once in the mocks that bypass it. The two drift apart silently until a bug ships to production.
PHP does not have generics. A method that returns array gives no compile-time guarantee about what the array contains. PHPDoc annotations like @return array<Book> help static analysers, but they are invisible at runtime. A wrong element slips in, and the error surfaces far from the insertion point.
In most PHP projects, cache logic ends up scattered across business code. The handler that executes the query also contains the caching logic: key generation, lookup, storage, TTL. Two responsibilities, cache code and business code, coexist in the same method.