On 18 July 2011 18:52, Sean P. DeNigris <sean@clipperadams.com> 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.