On 18 July 2011 18:52, Sean P. DeNigris <[email protected]> wrote: > > 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! >
This looks like a relevant: http://code.google.com/p/pharo/issues/detail?id=4485 > 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. > > -- Best regards, Igor Stasenko AKA sig.
