Which would you recommend for the implementation of a stub/mock lib? Thanks, trans.
on 2008-10-24 22:04
on 2008-10-25 02:01
On Oct 24, 2:04 pm, Trans <email@example.com> wrote: > Which would you recommend for the implementation of a stub/mock lib? An update to this question: In considering it most of the day, I've decided aliasing is a poor approach. The reason is singleton methods. Though singleton methods may be rare, their use by the SUT could end up clobbering stub methods. As an alternate to aliasing, singleton methods could be used to define stub methods. While they suffer the same potential problem, it is not an issue if good practices are used by the SUT, ie. extend objects with modules rather than defining singleton methods directly. So I guess the question has changed. It is now: Singleton Methods or Delegation? Related to this, one question I have about best practices of using stubs/mocks... Is it considered bad practice to stub/mock an internal SUT object? In other words, should stub/mocks always be temporary objects that are dropped into the SUT interfaces? (I hope that's clear enough.) Thanks, T.