tag:blogger.com,1999:blog-19626531.post4877265365234770047..comments2023-11-02T08:32:39.646+01:00Comments on Ola Bini: Programming Language Synchronicity: Java and mockingOla Binihttp://www.blogger.com/profile/15793488672952593953noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-19626531.post-57012470770152417122008-10-15T16:36:00.000+02:002008-10-15T16:36:00.000+02:00yes. java programming is too difficult. so hard to...yes. java programming is too difficult. so hard to learnAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-5022750590475180092008-09-11T05:06:00.000+02:002008-09-11T05:06:00.000+02:00i do not program using java. so difficulti do not program using java. so difficultAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-9726508064510051822008-08-08T12:06:00.000+02:002008-08-08T12:06:00.000+02:00Interesting, I don't often find myself interested ...Interesting, I don't often find myself interested in ensuring an interaction doesn't happen, I'll think think about that some more.<BR/><BR/>Having used several Java mocking frameworks and then Mockito, I'm now a fan of the latter.<BR/><BR/>The fundamental difference in my experience is Mockito's use of a TestSpy. This has allowed me to write more focused and concise tests that are simultaneously less brittle (more resilient to change) than a traditional interaction test that uses mocks (ala EasyMock/JMock).<BR/><BR/>In the Ruby, I'll use Pete Yandell's NotAMock with RSpec for the same benefits. It provides an easy way to create Test Spies and has complimentary Rspec matchers, so your expectations about interaction can be stated just like any other.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-42012290879242660282008-08-06T15:11:00.000+02:002008-08-06T15:11:00.000+02:00java is a very difficult language. i really cant g...java is a very difficult language. i really cant get it.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-60988968489292640922008-08-04T02:34:00.000+02:002008-08-04T02:34:00.000+02:00Try JMockit (different than JMock):https://jmockit...Try JMockit (different than JMock):<BR/><BR/>https://jmockit.dev.java.net/<BR/><BR/>It uses Java 5 instrumentation so it's more like the Mocha that we used to love without old-style Java restrictions.<BR/><BR/>See also:<BR/><BR/>http://java.dzone.com/articles/unit-testing-with-testng-and-j-0Hendyhttps://www.blogger.com/profile/05192845149798446052noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-54424625024957339342008-07-12T05:49:00.000+02:002008-07-12T05:49:00.000+02:00Very good post!I read the your interview in www.ak...Very good post!<BR/><BR/>I read the your interview in www.akitaonrails.com and quite liked.<BR/><BR/>Congratulations!<BR/><BR/>Bye<BR/><BR/>(codezone.wordpress.com)Leandro Silvahttps://www.blogger.com/profile/11294850733637211125noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-31295288415762159132008-07-10T17:01:00.000+02:002008-07-10T17:01:00.000+02:00>our approaches to how much >validation we do on b...>our approaches to how much >validation we do on both state and >behavior differ a bit.<BR/><BR/>Oh yes. I enjoy the level of validation known from typical state testing.<BR/><BR/>>So I need to guard against the NPE >with a toReturn, and do the verify >too.<BR/><BR/>Don't you think that not having NPE (because you did toReturn()) is enough proof that there is an interaction? I do. That's why I don't usually verify stubs... I guess this is another difference in our approaches to testing :)Szczepan Faberhttps://www.blogger.com/profile/12046847331523367866noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-75811529418957555212008-07-09T23:10:00.000+02:002008-07-09T23:10:00.000+02:00So, yeah. I guess our approaches to how much valid...So, yeah. I guess our approaches to how much validation we do on both state and behavior differ a bit.<BR/><BR/>But I think you misunderstood my point about null. The thing is, in a functional test having an interaction return null (since it's only verified, but not stubbed to return something) will mean that the code under test breaks on an NPE. But that will make the test fail, even though the thing I verified worked as it should. So I need to guard against the NPE with a toReturn, and do the verify too.Ola Binihttps://www.blogger.com/profile/15793488672952593953noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-67067093697152398342008-07-09T11:04:00.000+02:002008-07-09T11:04:00.000+02:00Hi Ola, you're gonna have a nice comment count on ...Hi Ola, you're gonna have a nice comment count on this one :)<BR/><BR/>>In fact, I generally look at surrounding state too.<BR/><BR/>Fair enough but I still believe that majority of state-based tests with assertions don't protect against 'the unexpected'. Other words, a typical assertion checks only single condition without worrying about surrounding state. Sometimes however - like in your scenario - you really want to be extra defensive which is fine.<BR/><BR/>>So, I need to verify stubs, since I need to make sure that the code under test doesn't break the surrounding code by returning null from the mocked out methods.<BR/><BR/>Returning null would break the test anyway because of NullPointerException. Therefore in most cases verifying stubs is redundant.Szczepan Faberhttps://www.blogger.com/profile/12046847331523367866noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-8165301299798357442008-07-08T21:03:00.000+02:002008-07-08T21:03:00.000+02:00Szczepan: Ok, so the short cut to generate a missi...Szczepan: Ok, so the short cut to generate a missing Java class I'm not sure about. I'm pretty sure it's there in IntelliJ, though. And in fact, what's interesting with using Ruby is that you can do TDD much easier: you don't even need to create the class under test before starting testing...<BR/><BR/>In fact, I generally look at surrounding state too. As a typical example I'm writing a PKCS#7 implementation right now, and for any updating operations I'm making sure that the state in that object is unchanged, except for the state I want to change. That gives me more security, and it also makes the process of updating some behavior mean that I need to update my tests. That's a good thing in my book. So no, I don't think interaction based testing is any different. I'm just testing more defensively than you seem to do.<BR/><BR/>Procedural vs functional has nothing to do with "tell, don't ask". What I mean with functional code is that most of my invocations return a value that is used in further processing. Typical example is immutable objects - which give your code lots of benefits. So immutable objects need to be returned as the result from interactions, and the chain continues like that. Which means that null is basically never right return value. In fact, returning null is almost always something that should break my code.<BR/><BR/>So, I need to verify stubs, since I need to make sure that the code under test doesn't break the surrounding code by returning null from the mocked out methods.<BR/><BR/>Yeah, renaming is good. Do that. We use JarJar Links.Ola Binihttps://www.blogger.com/profile/15793488672952593953noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-20945812056254739232008-07-08T11:09:00.000+02:002008-07-08T11:09:00.000+02:00>the tools questionFor me, the must-have IDE featu...>the tools question<BR/><BR/>For me, the must-have IDE feature is the ability to 'generate' source code from the test (some people call it TDD :P ). It's when I use classes/methods that don't exist yet, then ctrl+1 in Eclipse. If I can do it with JTestR then that's a big, big '+'.<BR/><BR/>>to increase readability and make the test focus on what they are actually testing<BR/><BR/>Totally agree, but I guess I don't think that static types or java testing frameworks are the main reason that many tests are unreadable :) Point taken, though.<BR/><BR/>>I almost _never_ want _any_ more calls than the ones I describe<BR/><BR/>Me too, but I guess I don't find it worth testing. It's like doing following for state based-testing:<BR/><BR/>expectedArticle.setRead(true);<BR/>article.read();<BR/>assertEquals(expectedArticle, article);<BR/><BR/>This way I make sure no other state was changed on the article other than 'read' (if read() method does something extra with a state then the test fails). But hey, no one writes state based tests like that. Is interaction testing really that different that it requires 'extra defensive' style? Think about it and let me know - I'm drafting a blog entry about it.<BR/><BR/>>the focus on procedural code<BR/><BR/>You mean that we prefer to "tell, don't ask"? In OO language like Java it works quite well.<BR/><BR/>>tests get longer and more complicated<BR/><BR/>When I care about return value it doesn't necessarily mean my tests become longer/complicated. I almost never verify() stubs because I worship <A HREF="http://monkeyisland.pl/2008/04/26/asking-and-telling" REL="nofollow">the difference between asking and telling</A> :)<BR/><BR/>>rename all the classes in CGlib, so they don't clash?<BR/><BR/>Excellent idea!!! Thank you for that!<BR/><BR/>Interesting post and interesting follow-ups!Szczepan Faberhttps://www.blogger.com/profile/12046847331523367866noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-60228842010215348992008-07-08T08:26:00.000+02:002008-07-08T08:26:00.000+02:00Szczepan:I kinda expected a response in this style...Szczepan:<BR/><BR/>I kinda expected a response in this style. =)<BR/><BR/>So first, yeah, the tools question. You know that IntelliJ can refactor Java code that's being used in Ruby, right?<BR/><BR/>But the longer story is that for me writing tests in Ruby is not to make them a few lines shorter. It's to increase readability and make the test focus on what they are actually testing. The types are seldom under test, and that means that they usually just get in the way. So why not omit them? The Ruby test frameworks are probably the best in the world.<BR/><BR/>Well, verifyNoMoreInteractions is an assertion that is so common, and so useful, that I would like to have an option to have it checked automatically. I almost _never_ want _any_ more calls than the ones I describe. In your first example, I would probably use verifyNoMoreInteractions, to make sure that the service only gets the two calls expected.<BR/><BR/>One of the problems I'm seeing in the example code for mocking in general and Mockito in particular, is the focus on procedural code. The problem is, I write in a functional style, and so do most other people who are fluent in other languages beside Java. The TestSpy approach makes it possible to check interactions afterwards, without setting up stubs/expectations, but only if you don't care about the return value. If you write in a functional style, your tests will have to set up the return values. Which means that either your tests gets longer and more complicated, or you drive your code to be more procedural. Both bad things.<BR/><BR/>I had more time yesterday, and checked why 1.4 broke things. As you say it was the cglib version that interacted badly with XStream. Have you considered doing what we do in JRuby with ASM, and rename all the classes in CGlib, so they don't clash?Ola Binihttps://www.blogger.com/profile/15793488672952593953noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-4040333980130460072008-07-07T18:15:00.000+02:002008-07-07T18:15:00.000+02:00In jMock you can ignore any methods you don't care...In jMock you can ignore any methods you don't care about, or even entire objects (and therefore the objects they return and so on). So you can avoid the problems you have with EasyMock of lots of test set-up. You can even ignore methods during set up and then expect them during the test. It's very configurable.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19626531.post-62267281179192022872008-07-06T22:33:00.000+02:002008-07-06T22:33:00.000+02:00Hi Ola,>Mocha, using JtestRJtestR is an interestin...Hi Ola,<BR/><BR/>>Mocha, using JtestR<BR/><BR/>JtestR is an interesting experiment. However, I couldn't give up on superior IDE support (refactoring, finding usages, autocomplete) just to cut few lines of test code. Writing test in a different language than a unit is quite adventurous, though :)<BR/><BR/>>verifyNoMoreInteractions() afterwards instead. <BR/>>It's way to easy to forget.<BR/><BR/>verifyNoMoreInteractions() is not a framework contract that you have to remember and write for every test method. verifyNoMoreInteractions() is just an assertion from the interaction testing toolkit. Use it only if it is relevant. Have a look at this dummy example:<BR/><BR/>someMethod() {<BR/> service.foo();<BR/> service.bar();<BR/>}<BR/><BR/>For above code I wouldn't use verifyNoMoreInteractions().<BR/><BR/>However in following scenario:<BR/><BR/>someMethod() {<BR/> if (condition) {<BR/> service.foo();<BR/> } else {<BR/> service.bar();<BR/> service.baz();<BR/> }<BR/>}<BR/><BR/>it perfectly makes sense to do the following:<BR/><BR/>shouldFooWhenCondition() {<BR/> ...<BR/> verify(service).foo();<BR/> verifyNoMoreInteractions(service);<BR/>}<BR/><BR/>I use verifyNoMoreInteractions() only if it describes relevant application code.<BR/><BR/>>Mockito 1.3 to 1.4 and see half our tests starting<BR/><BR/>We've upgraded the cglib version - perhaps your application already pulls in a different version? You can try with mockito-core.jar from zip distro. BTW, submitting a bug report is a nice way of supporting OSS (you do some OS don't you? :)Szczepan Faberhttps://www.blogger.com/profile/12046847331523367866noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-84761430310123490102008-07-06T01:54:00.000+02:002008-07-06T01:54:00.000+02:00I've been using Mockito of late, too, and my impre...I've been using Mockito of late, too, and my impression was that you typically didn't need to verify that stubbed methods were called.<BR/><BR/>Iirc, the reasoning is that you only stub method calls the code under test cares about, so if it's not called, the test will fail anyway. The Mockito guy explains it more clearly <A HREF="http://monkeyisland.pl/2008/04/26/asking-and-telling/" REL="nofollow">here</A>.<BR/><BR/>"One of the first things I noticed I don't like is that interactions that isn't verified can't be disallowed in an easy way"<BR/><BR/>I guess this is a bit of a compromise. If you've used EasyMock, then you know how annoying it is to have to specify every interaction, even the ones you aren't interested in. Overall, I prefer Mockito's choice, as specifically denying interactions can quickly feel like over-specifying.Moandji Ezanahttps://www.blogger.com/profile/01507510837237294496noreply@blogger.comtag:blogger.com,1999:blog-19626531.post-27333606773335683102008-07-05T07:07:00.000+02:002008-07-05T07:07:00.000+02:00JMock will throw an Error if any unspecified metho...<A HREF="http://www.jmock.org/index.html" REL="nofollow">JMock</A> will throw an Error if any unspecified methods are invoked on your mock object. For example, the call to iterator.next() will cause a unit test to fail:<BR/><BR/>//Java 4:<BR/>Mock mockIterator = mock(Iterator.class); mockIterator.expects(once()).method("hasNext").will(returnValue(true));<BR/><BR/>Iterator iterator = (Iterator) mockIterator.proxy();<BR/>assertTrue(iterator.hasNext());<BR/>iterator.next();<BR/><BR/>//Java 5:<BR/>final Iterator iterator = mock(Iterator.class);<BR/><BR/>checking(new Expectations(){{<BR/> one(iterator).hasNext();will(returnValue(false));<BR/>}});<BR/> <BR/> assertFalse(iterator.hasNext());<BR/>iterator.next();<BR/><BR/>Of course, Java does not permit you to express this as concisely as Ruby does. And no, you can't retain the behaviour of the original class :-(Caleb Powellhttps://www.blogger.com/profile/02676461951459695625noreply@blogger.com