tag:blogger.com,1999:blog-22587889.post2499619035698218270..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Making Classes Unit-TestableAnonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-22587889.post-64175550679177020052011-11-11T05:20:25.182+05:302011-11-11T05:20:25.182+05:30Thank you for this very nice article !Thank you for this very nice article !Adilhttp://www.squidcs.comnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-33356598957722114552007-04-02T18:10:00.000+05:302007-04-02T18:10:00.000+05:30Static methods are the equivalent of functional pr...Static methods are the equivalent of functional programming, which is fine if you are willing to give up the benefits of OO. They make sense in a lot of cases, for example utility methods like Math.abs, but as soon as they do anything more complicated, like fetch something from a database, it's time to refactor for a variety of reasons, not the least of which is testability. This is where the DAO pattern came from.<BR/><BR/>In previous projects the typical data access pattern involved static methods in the model for fetching objects from the database (or cache). This has obvious implications on unit testing that class and others that depend on that class. My favorite solution to the unit testing dilemma was to extract an interface to define a data access facade, implement it for production by delegating to the static methods, and mock it for unit testing.<BR/><BR/>This way existing code can still call the static methods directly, but over time legacy code that is being brought under test could be refactored to use the facade. Either a dependency injecting factory or a simple factory method that can be overridden in the test is all it takes to provide the appropriate facade implementation.Jeremy Weiskottenhttps://www.blogger.com/profile/01868696039970401724noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-51533100191467536662007-04-02T15:03:00.000+05:302007-04-02T15:03:00.000+05:30Using static methods on many service methods will...Using static methods on many service methods will cause procedural program flow so I think this static vs. instance methods will set up base for application and its program flow.<BR/><BR/>For me this also means anemic domain model vs rich domain model.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-59865500448974264192007-04-02T14:19:00.000+05:302007-04-02T14:19:00.000+05:30I understand that instance-based mocking is easier...I understand that instance-based mocking is easier, but there is the slight penalty of code being a bit harder to understand. Math.min(2,3) works, and we never feel the need to mock it, so why do we feel the need to mock out other static methods?<BR/><BR/>Tests that depend on functionality from more than one place is ok, and actually unavoidable. If you write tests for your static methods, then there's no reason not to use those static methods elsewhere.<BR/><BR/>Converting statics to instance methods? YAGNI.Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-16916202231216913122007-04-02T13:45:00.000+05:302007-04-02T13:45:00.000+05:30I think in first static example there is also othe...I think in first static example there is also other code smell. I would put these calculations that TradeUtils does in domain model and avoid this kind of utility classes.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-79121483144262023262007-04-02T13:41:00.000+05:302007-04-02T13:41:00.000+05:30We used AspectJ in last project to get static meth...We used AspectJ in last project to get static methods tested. In my opinion it was not too easy or convinient. Too much hassle to get simple tests working...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-5238871929052152722007-03-31T23:21:00.000+05:302007-03-31T23:21:00.000+05:30[for ricky]:The advantage of using non-static meth...<I>[for ricky]:</I><BR/>The advantage of using non-static method is that the instance can always be mocked appropriately, more so using an IoC like Spring or Guice. For statics, mocking is difficult and makes the code tightly coupled to the class whose static method is used.<BR/><BR/>I agree with ur observations in Scheme (which can also be done in Ruby), where metaprogramming can make you reach very obscure corners of the programs. But again, my whole post was based on Java, where we need to deal with a static class model. And yes, AOP can always be used to do all sorts of magic.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-3286281996845078922007-03-31T23:09:00.000+05:302007-03-31T23:09:00.000+05:30A broken static method can break a test just as ea...A broken static method can break a test just as easily as a broken non-static method can.<BR/><BR/>Static methods are simple to use. It's easy to read code that uses static methods. It's not so easy to mock them out, but perhaps AOP can help there too. In Scheme at least, you can rebind a function temporarily. It's a shame that Java's class model is so static.<BR/><BR/>In short, if you have to write harder-to-read code to make it testable, then there's something wrong with the language.Ricky Clarksonhttps://www.blogger.com/profile/13845104548520132930noreply@blogger.com