This looks like a slightly different problem to me, where something has a hardcoded, hidden dependency (a global class object), which is not substitutable by design, but we want to replace it from the test to something that answers the canned value.
I understand the practical arguments that probably nobody will ever want to replace the clock to an other one in production. But making the replaceable clock dependency is not the only option (though, making explicit that something is time dependent can be useful sometimes). Many times it is possible to get rid of the clock entirely at the current level and introduce a higher level abstraction that can respond to messages like, #isTrialPeriodExpired, #hasDayChangedFrom, #shouldCacheBeInvalidated depending on the domain. And this object can be mocked easily in test of its collaborator. Of course sometimes this is not possible or doesn't worth the effort. jb rainsberger had an interesting post about this http://blog.thecodewhisperer.com/2013/11/23/beyond-mock-objects/ Sean P. DeNigris wrote > For sure, there are times when this could be abused. But the spirit of > Smalltalk is to trust the programmer with the full power of the computer > at every level (e.g. private methods are only a suggestion). This is a valid argument, but my point of view is different. I think the purpose of doing TDD is lost because of those shortcuts. It is easy to fall back to testing mode, and focus on the problem, how do I test something, instead of design something which is testable and therefore changeable without those shortcuts. -- View this message in context: http://forum.world.st/ANN-BabyMock-2-tp4748530p4756230.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
