Fast tests can lead to a fast system
I prefer to avoid caching whenever possible. It adds a lot of complexity. Caching and data-de-normalization are basically the same thing... replicating data and state.
De-normalization makes testing much harder. Extremely fast tests make testing easier (and far less painful). TDD makes testing for all the edge cases associated with de-normalized data easier. In other words, if cache expiration is a hard problem, then it should be addressed within the fast tests, not bolted on afterwards, or with an external system.
All the truly hard problems should be within the internal system (caching, system state, routing), which makes the inside of the system not really the testing-concept-the-happy-zone but rather the fast-zone (but the fast zone is also happy because it's fast).
Caching becomes an integral, well tested, part of the software. You can use it much more aggressively, greatly speeding up your application, without worrying as much about the complexity that it brings.
Fast tests also encourage refactoring. You can refactor code into a nice abstraction, establishing single-choke-points. Once those choke points are established, they can make for easy places to concentrate performance effort if performance testing shows they are slow.