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.
