tag:blogger.com,1999:blog-5638372.post110280383008003933..comments2023-10-10T05:22:56.347-05:00Comments on binkley's BLOG: The easy wayBrian Oxleyhttp://www.blogger.com/profile/06617364377560752378noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-5638372.post-1102991417001002842004-12-13T20:30:00.000-06:002004-12-13T20:30:00.000-06:00I'm familiar with the technique you describe -- it...I'm familiar with the technique you describe -- it's what I recommend to my coworkers. :-) I was looking for a minimal change in the existing code base to pull off the trick of stubbing out calls to a physical device.<br /><br />I want to make the distinction between a stub and a mock. A mock is programmable and supports verification of calls (as you mention). But stub I mean something rather dumber which is 'just enough' to get buy, but no more.<br /><br />When I revisit the code base, I plan on going for IoC whole hog, using interfaces, and fixing the problem root and stock.<br /><br />Thanks for commenting!Brian Oxleyhttps://www.blogger.com/profile/06617364377560752378noreply@blogger.comtag:blogger.com,1999:blog-5638372.post-1102955994293399582004-12-13T10:39:00.000-06:002004-12-13T10:39:00.000-06:00Sorry, should have told you who was posting that a...Sorry, should have told you who was posting that advice so you know who to blame if it's wrong. Anonymous posts wind me up. - LizAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-5638372.post-1102955919622966942004-12-13T10:38:00.000-06:002004-12-13T10:38:00.000-06:00Hi Brian,
The normal way to use mocks is somethin...Hi Brian,<br /><br />The normal way to use mocks is something like:<br /><br />public class MockDevice extends MockObject implements Device {<br />...<br />}<br /><br />Without this you lose the auto-verify functionality of MockObjects. Also some dynamic Mock libraries require interfaces; I'm told this is true of EasyMock and believe JMock's similar.<br /><br />Even further; the danger of extending a real class in your MockObject is that the class under test might end up calling a real method you didn't know about. With an interface, that doesn't happen - if you don't mock the method, you get an error.<br /><br />You can certainly get around this by using a factory or a registry if you only ever need one of them:<br /><br />public class DeviceRegistry() {<br /> private Device device;<br /><br /> public Device getDevice() {<br /> if (device == null) {<br /> device = new DeviceImpl();<br /> }<br /> return device;<br /> }<br />}<br /><br />You can then use reflection as before to make device be a MockDevice. Add registerDevice methods etc. if it seems appropriate. This is on the limit of stuff I know, so others may disagree or improve, but I hope it's helpful. It's what I'd do now I've seen how great dynamic mocks are (if I couldn't use inversion of control, anyway).Anonymousnoreply@blogger.com