http://blog.gmane.org/gmane.comp.java.jmock.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.java.jmock.devel/156 Deprecate the 'one' method in favour of 'oneOf' ----------------------------------------------- Key: JMOCK-205 URL: http://jira.codehaus.org/browse/JMOCK-205 Project: jMock Issue Type: New Feature Components: Library Reporter: Nat Pryce Priority: Trivial Nat Pryce (JIRA 2008-09-15T20:34:48 http://comments.gmane.org/gmane.comp.java.jmock.devel/152 Documentation does not use the oneOf method ------------------------------------------- Key: JMOCK-204 URL: http://jira.codehaus.org/browse/JMOCK-204 Project: jMock Issue Type: Bug Components: Documentation, Library Affects Versions: 2.5.0, 2.5.1 Reporter: Justin Wesley Priority: Minor The CardinalityClause interface should have the 'oneOf' method since the 'one' method is expected to be deprecated according to the documentation in Expectations. These methods should also be annotated as deprecated. The documentation should also be changed to reflect this change in API. I noticed 'one' is referenced in the sections 'Getting Started', 'Cookbook', and 'Cheat Sheet'. Nat Pryce (JIRA 2008-09-15T20:30:48 http://comments.gmane.org/gmane.comp.java.jmock.devel/149 CardinalityClause does not include new oneOf method --------------------------------------------------- Key: JMOCK-203 URL: http://jira.codehaus.org/browse/JMOCK-203 Project: jMock Issue Type: Bug Components: Documentation, Library Affects Versions: 2.5.1, 2.5.0 Reporter: Justin Wesley Priority: Minor The CardinalityClause interface should have the 'oneOf' method since the 'one' method is expected to be deprecated according to the documentation in Expectations. These methods should also be annotated as deprecated. The documentation should also be changed to reflect this change in API. I noticed 'one' is referenced in the sections 'Getting Started', 'Cookbook', and 'Cheat Sheet'. Justin Wesley (JIRA 2008-09-15T16:24:48 http://comments.gmane.org/gmane.comp.java.jmock.devel/147 Unsatisfied expectations are not correctly captured with JUnit4's < at >Test(expected=AssertionError.class) in JMock 2.5.0-RC1+ -------------------------------------------------------------------------------------------------------------------------- Key: JMOCK-202 URL: http://jira.codehaus.org/browse/JMOCK-202 Project: jMock Issue Type: Bug Affects Versions: 2.5.1, 2.5.0, 2.5.0-RC1 Environment: JMock 2.5.0-RC1+ JUnit 4.4 Java 1.5.0_16 Ubuntu Linux 8.0.4 kernel 2.6.24-19-generic Reporter: Steven Cummings Attachments: JMockBugTest.java This was working up through version 2.4.0. I am testing some custom matchers with JMock by writing expectations that I expect to be unsatisfied when the test completes, and therefore I expect an AssertionError. From JMock 2.5.0-RC1 and on, < at >RunWith(JMock.class) causes < at >Test(expected=AssertionError.class) to fail to capture the resulting exception. When I say JMock 2.5.0-RC1+, I mean I could reproduce the problem with versions 2.5.0-RC1, 2.5.0, 2.5.0.1, and 2.5.1. Steven Cummings (JIRA 2008-09-02T18:22:48 http://comments.gmane.org/gmane.comp.java.jmock.devel/146 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email snackbox-KvP5wT2u2U0< at >public.gmane.org 2008-08-29T20:27:52 http://comments.gmane.org/gmane.comp.java.jmock.devel/145 Allow ClassImposteriser to be extended -------------------------------------- Key: JMOCK-201 URL: http://jira.codehaus.org/browse/JMOCK-201 Project: jMock Issue Type: Improvement Components: Library Affects Versions: 2.5.1 Reporter: Corporate Gadfly I had a need to imposterise concrete classes (from 3rd-party jars) with final toString() method. For background, please see discussion at: http://www.nabble.com/Re%3A-mocking-concrete-classes-with-final-toString-method-p18509146.html In that thread, Nat had advised one of the options as being "write your own Imposteriser". So, for my needs I ended up writing ClassImposteriserAllowingFinalToString. It would be great if ClassImposteriser could be made easier to extend. As it is, it has a lot of private methods and properties and I pretty much had to rewrite my own imposteriser from scratch (essentially duplicating the private pieces of ClassImposteriser). If ClassImposteriser was extension friendly, I would probably need to do minimal work by writing my own imposterise() and canImposterise() methods. This way I would also be safeguarded against future bug-fixes that may happen in ClassImposteriser. Cheers and thanks in advance. Corporate Gadfly (JIRA 2008-08-29T16:32:48 http://comments.gmane.org/gmane.comp.java.jmock.devel/144 We've just released jMock 2.5.1, a bug-fix release that improves error messages. The changelog is at: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10336&styleName=Html&version=14527 --Nat --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email Nat Pryce 2008-08-24T10:20:55 http://comments.gmane.org/gmane.comp.java.jmock.devel/141 JMock does not report actual invocations when the mockery is not satisfied -------------------------------------------------------------------------- Key: JMOCK-200 URL: http://jira.codehaus.org/browse/JMOCK-200 Project: jMock Issue Type: Bug Components: Library Affects Versions: 2.5.0 Reporter: Nat Pryce Priority: Minor Nat Pryce (JIRA 2008-08-24T00:02:26 http://comments.gmane.org/gmane.comp.java.jmock.devel/139 Upgrade to CGLIB 2.2 -------------------- Key: JMOCK-199 URL: http://jira.codehaus.org/browse/JMOCK-199 Project: jMock Issue Type: Improvement Components: Library Affects Versions: 2.5.0 Reporter: Nat Pryce Fix For: 2.6.0 Nat Pryce (JIRA 2008-08-13T22:23:27 http://comments.gmane.org/gmane.comp.java.jmock.devel/109 Hi I'm trying to build from source but all (tried) revisions after r1193 fail (output from r1280 build) $ ant Buildfile: build.xml clean: [delete] Deleting directory /home/marcos/jmock/trunk/jmock2/build dir.build: [mkdir] Created dir: /home/marcos/jmock/trunk/jmock2/build compile: [mkdir] Created dir: /home/marcos/jmock/trunk/jmock2/build/classes [javac] Compiling 175 source files to /home/marcos/jmock/trunk/jmock2/build/classes [javac] /home/marcos/jmock/trunk/jmock2/src/org/jmock/lib/concurrent/DeterministicScheduler.java:28: org.jmock.lib.concurrent.DeterministicScheduler is not abstract and does not override abstract method <T>invokeAny(java.util.Collection<? extends java.util.concurrent.Callable<T>>,long,java.util.concurrent.TimeUnit) in java.util.concurrent.ExecutorService [javac] public class DeterministicScheduler implements ScheduledExecutorService { [javac] ^ [javac] 1 error BUILD FAILED /home/marcos/jmock/trunk/jmock2/build.xml:60: Compile failed; see the compiler error output for details. (output from r1194 build) $ ant Buildfile: build.xml clean: [delete] Deleting directory /home/marcos/jmock/trunk/jmock2/build dir.build: [mkdir] Created dir: /home/marcos/jmock/trunk/jmock2/build compile: [mkdir] Created dir: /home/marcos/jmock/trunk/jmock2/build/classes [javac] Compiling 159 source files to /home/marcos/jmock/trunk/jmock2/build/classes [javac] /home/marcos/jmock/trunk/jmock2/src/org/jmock/lib/concurrent/SynchronousScheduledExecutor.java:23: org.jmock.lib.concurrent.SynchronousScheduledExecutor is not abstract and does not override abstract method <T>invokeAny(java.util.Collection<? extends java.util.concurrent.Callable<T>>,long,java.util.concurrent.TimeUnit) in java.util.concurrent.ExecutorService [javac] public class SynchronousScheduledExecutor implements ScheduledExecutorService { [javac] ^ [javac] 1 error BUILD FAILED /home/marcos/jmock/trunk/jmock2/build.xml:59: Compile failed; see the compiler error output for details. MSanchez 2008-08-04T21:14:43 http://comments.gmane.org/gmane.comp.java.jmock.devel/107 Allow assert of State-Machine ----------------------------- Key: JMOCK-198 URL: http://jira.codehaus.org/browse/JMOCK-198 Project: jMock Issue Type: Improvement Components: Library Affects Versions: 2.5.0 Reporter: Marcos Sanchez Priority: Trivial Asserting a state-machine's state requires the internal API (not obvious, clear or documented) as in assertTrue(stateMachine.is("desired-state").isActive()); assertTrue(stateMachine.isNot("undesirable-state").isActive()) I suggest the creation of a become("state") counterpart. Maybe something like isCurrently("state") & isNotCurrently("state") which wrap the internal API, such that we get assertTrue(stateMachine.isCurrently("state")); assertTrue(stateMachine.isNotCurrently("state")); Marcos Sanchez (JIRA 2008-08-04T18:19:26 http://comments.gmane.org/gmane.comp.java.jmock.devel/101 Mocking a static nested class causes a net.sf.cglib.core.CodeGenerationException to be thrown. ---------------------------------------------------------------------------------------------- Key: JMOCK-197 URL: http://jira.codehaus.org/browse/JMOCK-197 Project: jMock Issue Type: Bug Affects Versions: 1.2.0 Reporter: Ryan C. Payne In some code that I have inherited I have a class with a static nested class. In the past (jMock 1.1.0) I was able to successfully mock this static nested class. After upgrading to jMock 1.2.0, this no longer works. I end up getting the following exception: net.sf.cglib.core.CodeGenerationException: java.lang.IllegalAccessError-->tried to access method org.jmock.codegen.com.mycompany.core.util.DataPage$DataPageDefinition$$EnhancerByCGLIB$$3417fee6.CGLIB$setPageNumber$6(I)V from class org.jmock.codegen.org.jmock.codegen.com.mycompany.core.util.DataPage$DataPageDefinition$$EnhancerByCGLIB$$3417fee6$$FastClassByCGLIB$$e9f65fd5 at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:235) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220) at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:636) at net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:538) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:225) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:304) at org.jmock.cglib.CGLIBCoreMock.<init>(CGLIBCoreMock.java:63) at org.jmock.cglib.CGLIBCoreMock.<init>(CGLIBCoreMock.java:46) at org.jmock.cglib.CGLIBCoreMock.<init>(CGLIBCoreMock.java:35) at org.jmock.cglib.MockObjectTestCase.newCoreMock(MockObjectTestCase.java:33) at org.jmock.MockObjectTestCase.mock(MockObjectTestCase.java:67) at org.jmock.MockObjectTestCase.mock(MockObjectTestCase.java:55) at com.mycompany.core.persistence.hbm.HBMBaseDAOTest.testLimitResultSet(HBMBaseDAOTest.java:117) Caused by: java.lang.IllegalAccessError: tried to access method org.jmock.codegen.com.mycompany.core.util.DataPage$DataPageDefinition$$EnhancerByCGLIB$$3417fee6.CGLIB$setPageNumber$6(I)V from class org.jmock.codegen.org.jmock.codegen.com.mycompany.core.util.DataPage$DataPageDefinition$$EnhancerByCGLIB$$3417fee6$$FastClassByCGLIB$$e9f65fd5 at org.jmock.codegen.org.jmock.codegen.com.mycompany.core.util.DataPage$DataPageDefinition$$EnhancerByCGLIB$$3417fee6$$FastClassByCGLIB$$e9f65fd5.invoke(<generated>) at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:167) at org.jmock.cglib.CGLIBCoreMock.intercept(CGLIBCoreMock.java:79) at org.jmock.codegen.com.mycompany.core.util.DataPage$DataPageDefinition$$EnhancerByCGLIB$$3417fee6.setPageNumber(<generated>) at com.mycompany.core.util.DataPage$DataPageDefinition.<init>(DataPage.java:280) at com.mycompany.core.util.DataPage$DataPageDefinition.<init>(DataPage.java:267) at org.jmock.codegen.com.mycompany.core.util.DataPage$DataPageDefinition$$EnhancerByCGLIB$$3417fee6.<init>(<generated>) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:228) ... 58 more Research led me to the following: http://www.gg3721.com/list/50/44427.html and the followup http://www.gg3721.com/list/50/44774.html Ryan C. Payne (JIRA 2008-07-30T01:44:27 http://comments.gmane.org/gmane.comp.java.jmock.devel/100 patch to maven packaging to generate source jars with source ------------------------------------------------------------ Key: JMOCK-196 URL: http://jira.codehaus.org/browse/JMOCK-196 Project: jMock Issue Type: Improvement Components: Maven Packaging Affects Versions: 2.5.0 Reporter: peter royal Assignee: Mauro Talevi Fix For: Chore (ASAP) Attachments: jmock-source-jars.diff see attached patch. it separates out the source/classes from the original jar and treats them as "generated sources" for maven, so then the -sources jar created has the right stuff. peter royal (JIRA 2008-07-24T04:51:26 http://comments.gmane.org/gmane.comp.java.jmock.devel/99 Hello gcjjd-dev-new< at >m.gmane.org You have successfully subscribed to dev-sXN/XchZ9OexIXFVlbCvtR2eb7JE58TQ< at >public.gmane.org using this email address. Thanks, Codehaus Support Codehaus Xircles 2008-07-22T03:12:03 http://comments.gmane.org/gmane.comp.java.jmock.devel/97 Working on an example, it struck me we should consider some sugar for the most common cases: one(T) -> exactly(1).of(T) returning() -> will(returnValue()) throwing() -> will(throwException()) e.g. mockery.expects(new InAnyOrder() {{ allowing(connection).createStatement(); returning(statement); one(statement).executeQuery(with(startsWith("select next"))); returning(resultSet); one(resultSet).next(); returning(true); one(resultSet).getInt("next"); returning(99); one(statement).close(); }}); hmmm, at that point do we just offer? mockery.expects(new InAnyOrder() {{ allowing(connection).createStatement(); returning(statement); statement.executeQuery(with(startsWith("select next"))); returning (resultSet); resultSet.next(); returning(true); resultSet.getInt("next"); returning(99); statement.close(); }}); which takes us to being a better implemented EasyMock mockery.expects(new InAnyOrder() {{ allowing( connection.createStatement() ).returning(statement); one( statement.executeQuery(with(startsWith("select next"))) ).returning(resultSet); one( resultSet.next() ).returning(true); one( resultSet.getInt("next") ).returning(99); one().of(statement).close(); }}); Hmmm. S. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email Steve Freeman 2006-10-12T16:02:20 http://comments.gmane.org/gmane.comp.java.jmock.devel/97 Working on an example, it struck me we should consider some sugar for the most common cases: one(T) -> exactly(1).of(T) returning() -> will(returnValue()) throwing() -> will(throwException()) e.g. mockery.expects(new InAnyOrder() {{ allowing(connection).createStatement(); returning(statement); one(statement).executeQuery(with(startsWith("select next"))); returning(resultSet); one(resultSet).next(); returning(true); one(resultSet).getInt("next"); returning(99); one(statement).close(); }}); hmmm, at that point do we just offer? mockery.expects(new InAnyOrder() {{ allowing(connection).createStatement(); returning(statement); statement.executeQuery(with(startsWith("select next"))); returning (resultSet); resultSet.next(); returning(true); resultSet.getInt("next"); returning(99); statement.close(); }}); which takes us to being a better implemented EasyMock mockery.expects(new InAnyOrder() {{ allowing( connection.createStatement() ).returning(statement); one( statement.executeQuery(with(startsWith("select next"))) ).returning(resultSet); one( resultSet.next() ).returning(true); one( resultSet.getInt("next") ).returning(99); one().of(statement).close(); }}); Hmmm. S. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email Steve Freeman 2006-10-12T16:02:20 http://comments.gmane.org/gmane.comp.java.jmock.devel/94 More fun with JMock 2. org.jmock.internal is listed as "use at your own risk", but I find it hard to write useful tests without the allowing(), etc methods of ExpectationGroupBuilder. Should the API shift some? Thanks, David Saff --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email David Saff 2006-10-11T15:14:07 http://comments.gmane.org/gmane.comp.java.jmock.devel/94 More fun with JMock 2. org.jmock.internal is listed as "use at your own risk", but I find it hard to write useful tests without the allowing(), etc methods of ExpectationGroupBuilder. Should the API shift some? Thanks, David Saff --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email David Saff 2006-10-11T15:14:07 http://comments.gmane.org/gmane.comp.java.jmock.devel/93 I downloaded the jmock2 and hamcrest projects, imported them into Eclipse, and made my project dependent on both. Originally, I put hamcrest first on the classpath, which confused the compiler, because hamcrest includes a jmock-1.x.jar on its classpath, and the JMock 1 definition of Invocation was trumping the JMock 2 definition of Invocation. Is this something to solve in hamcrest, or just something to note in the JMock 2 README? Thanks, David Saff --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email David Saff 2006-10-11T15:04:20 http://comments.gmane.org/gmane.comp.java.jmock.devel/93 I downloaded the jmock2 and hamcrest projects, imported them into Eclipse, and made my project dependent on both. Originally, I put hamcrest first on the classpath, which confused the compiler, because hamcrest includes a jmock-1.x.jar on its classpath, and the JMock 1 definition of Invocation was trumping the JMock 2 definition of Invocation. Is this something to solve in hamcrest, or just something to note in the JMock 2 README? Thanks, David Saff --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email David Saff 2006-10-11T15:04:20 http://comments.gmane.org/gmane.comp.java.jmock.devel/74 jMock 2 now has the following, additional features: - You can specify complex ordering constraints by nesting "InAnyOrder" and "InThisOrder" blocks - You can use a jMock 1 style to specify expectations that are more flexible than can be captured by real method calls, such as allowing calls to any bean getter or to any mock object of a given type. - Error messages have been improved. However, we need some alpha testers to help drive out the corner cases and tough bugs and give us feedback on the API. So, if you're interested please check it out of CVS and play around with it: the correct CVS location is on the www.jmock.org site. Read the acceptance tests for examples of how to use it. --Nat. --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email Nat Pryce 2006-09-22T12:19:39 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.jmock.devel