tag:blogger.com,1999:blog-15929719.post5244529145588475582..comments2023-10-21T01:56:53.775-07:00Comments on Van Couvering Is Not a Verb: Shut up and write those testsAnonymoushttp://www.blogger.com/profile/04898259486137280102noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-15929719.post-74864954319445185382009-07-09T06:41:14.782-07:002009-07-09T06:41:14.782-07:00I'd just like to share my experience with mock...I'd just like to share my experience with mocking...<br /><br />A problem with the use of mocks is that it's not easy to read (even with Mockito). Sure, you can cleanly state your fake behaviors individually, but I've yet to find a way to make it naturally fit a test structure (I mean, as part of the test, what does it all mean?).<br /><br />For example, in your test, sure you've managed to nail down _messageManager.sendCheckpoint(...)'s behavior, but the test falls short as a specification. And if your test is hard to understand, other developers might not bother fixing it properly once it breaks. <br /><br />And to make matters worse, mock-base tests tend to be brittle. Thus if your mock-base test breaks, it might not necessarily mean that the functionality broke. It could simple mean the implementation change though the output/behavior is still the same (and it happens more often than you think..which may lead you to loosen up the expectations..which may in turn fail to capture scenario ....it's a give & take).<br /><br />Furthermore, mock-base characterization tests does not offer much guarantee in terms of refactoring existing code (since it is coupled with specific implementation).<br /><br />..Anyway, if anybody knows how to cleanly right mocks (as part of the whole test), and in a matter that it does not cry wolf, I'm all ears.Franz Seehttps://www.blogger.com/profile/02185658313346099066noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-52637219655572944602009-07-02T06:30:40.615-07:002009-07-02T06:30:40.615-07:00Didn't know that.
One nice thing that I found ...Didn't know that.<br />One nice thing that I found groovy can do was mock out static method calls like Thread.startDaemon(), which I needed on a recent grails project I was working on.<br /><br />Thread.metaClass.static.startDaemon = {Closure c -> c.call()}jlorenzenhttps://www.blogger.com/profile/13635369821860631868noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-33691167580900358732009-07-01T11:56:13.317-07:002009-07-01T11:56:13.317-07:00Groovy looks nice, but it sure looks like you can ...Groovy looks nice, but it sure looks like you can do all this with Mockito. In general it's easy to write simple "thenReturn" kind of statements, but you can have a mocked routine run an entire method that does whatever you want if you so desire.Anonymoushttps://www.blogger.com/profile/04898259486137280102noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-774102456030224142009-06-30T20:32:36.043-07:002009-06-30T20:32:36.043-07:00I agree, the jmockit syntax is too verbose.
I cont...I agree, the jmockit syntax is too verbose.<br />I continue to hear good things about mockito, but I think I still prefer testing java code using groovy. Groovy provides several methods to create mocks including metaClass. IMO it even more readable and easier than other java mocking frameworks. Read here for more: http://jlorenzen.blogspot.com/2009/04/mock-testing-with-groovy.htmljlorenzenhttps://www.blogger.com/profile/13635369821860631868noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-32093019723819910632009-06-30T14:54:31.918-07:002009-06-30T14:54:31.918-07:00Hm, the book says the same thing you do: only refa...Hm, the book says the same thing you do: only refactor with a good test suite already in place. Some of the techniques have changed, but the principle is the same. <br /><br />For example, you can't inject mock objects if the objects are created inside the constructor. You can't add a test for certain behavior that you want to refactor if that behavior is embedded in a big method. The trick is how to write tests *before* you refactor, and that's what this book is all about.<br /><br />BTW, IMHO the Mockito syntax is more readable than what you showed me with JMockit.Anonymoushttps://www.blogger.com/profile/04898259486137280102noreply@blogger.comtag:blogger.com,1999:blog-15929719.post-19303444481070284432009-06-30T13:34:08.695-07:002009-06-30T13:34:08.695-07:00That is a great book, but it's five years old....That is a great book, but it's five years old. Things have changed since then.<br /><br />Ideally, refactoring of code in use should only be done with a good test suite already in place. Back then, this was not possible because of limited testing tools.<br /><br />Today, <em>any</em> code is testable, if the proper mocking tool is used. You can leave the "hairball of existing code" as is initially, write all the unit tests you want, and then start refactoring to improve the design. In the end, you won't even have to refactor as much, since it's not necessary to work around limitations of the mocking tool.<br /><br />The tool I am talking about is <a href="https://jmockit.dev.java.net" rel="nofollow">JMockit</a>.<br /><br />Using it, your example code would look like this:<br /><br />public void testSendCheckPoint(<br /> final Checkpointable mockCheckpointable, <br />final CrawlerContent mockCrawlerContent, final ContentStream mockContentStream)<br />{<br /> final List crawlerItems = new ArrayList();<br /> crawlerItems.add(mockCrawlerContent);<br /><br /> new NonStrictExpectations() {{<br /> mockCheckpointable.getItems(); returns(crawlerItems);<br /> mockCrawlerContent.getContentStream(); returns(mockContentStream);<br />}};<br /> _messageManager.sendCheckpoint(mockCheckpointable);<br /><br /> new Verifications() {{<br />_mockContentBuffer.handleContentFromCrawler(mockContentStream, mockCrawler);<br /> _mockWalkUpdater.handleCheckpoint(mockCheckpointable);<br /> }};<br />}Anonymoushttps://www.blogger.com/profile/04604988940435731609noreply@blogger.com