Carlo wrote:
Personally when I come across cases like this I either break the (usually public) method into a public and internal method, the internal method contains the date so we can test the edge cases.
The thing I don't like about this is that I often load a package I've never used before and go to the tests, which I believe should be examples of how to use the class, yet I find tests that are not from the POV of a user and give me less direction than I'd like. With this method, the sin-to-make-it-testable is on display in the action step of the test instead of hidden away in the setup as it could be with a stub. Carlo wrote:
Another option which you've probably decided against is to delegate to your current class or a Registry to ask for the class with which to use for date related tasks, a kind of factory in a way.
Yes, this is the best way I can think of, but it feels like a hack. Carlo wrote:
I personally feel Pharo is moving into a more pluggable direction with the work on the environment (Smalltalk environment) where we can provide our own environment for a particular context
That would be awesome! Thanks. Sean -- View this message in context: http://forum.world.st/Stubbing-class-side-methods-tp3674065p3675843.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.