You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(13) |
Aug
(151) |
Sep
(21) |
Oct
(6) |
Nov
(70) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(47) |
Feb
(66) |
Mar
(23) |
Apr
(115) |
May
(24) |
Jun
(53) |
Jul
(10) |
Aug
(279) |
Sep
(84) |
Oct
(149) |
Nov
(138) |
Dec
(52) |
2003 |
Jan
(22) |
Feb
(20) |
Mar
(29) |
Apr
(106) |
May
(170) |
Jun
(122) |
Jul
(70) |
Aug
(64) |
Sep
(27) |
Oct
(71) |
Nov
(49) |
Dec
(9) |
2004 |
Jan
(7) |
Feb
(38) |
Mar
(3) |
Apr
(9) |
May
(22) |
Jun
(4) |
Jul
(1) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(15) |
Dec
(2) |
2005 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(28) |
Jun
(3) |
Jul
(11) |
Aug
(5) |
Sep
(1) |
Oct
(5) |
Nov
(2) |
Dec
(3) |
2006 |
Jan
(8) |
Feb
(3) |
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jeff M. <cus...@us...> - 2004-04-29 10:14:01
|
Update of /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/io In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23893/src/jdk/common/com/mockobjects/io Modified Files: MockIOFactory.java Log Message: Change iofactory to return the value not the returnvalue container Index: MockIOFactory.java =================================================================== RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/io/MockIOFactory.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- MockIOFactory.java 11 Aug 2003 09:16:30 -0000 1.4 +++ MockIOFactory.java 29 Apr 2004 10:13:49 -0000 1.5 @@ -24,7 +24,7 @@ } public void setupOutputStream(File expectedFile, OutputStream returnStream) { - this.outputStream.putObjectToReturn(expectedFile, outputStream); + this.outputStream.putObjectToReturn(expectedFile, returnStream); } public OutputStream createOutputStream(File aFile) throws FileNotFoundException { |
From: <tk...@10...> - 2004-04-29 07:44:20
|
The current source code does not compile with J2SE 1.3. That's because the below mentioned classes throw an AssertionError which was introduced with J2SE 1.4. test.mockobjects.dynamic.InvocationMockerTest$MockStub test.mockobjects.dynamic.support.MockCallable test.mockobjects.dynamic.support.MockInvocationDispatcher test.mockobjects.dynamic.support.MockInvokable Changed the AssertionError into an AbstractMethodError. Regards, Tomy |
From: <tk...@10...> - 2004-04-28 11:53:42
|
test.mockobjects.AutoTestSuite searches for unit test classes on the classpath and runs the corresponding unit tests. To do this it has to convert file system paths to class names. It does this correctly on Unix type systems but fails on Win32. The attached patch corrects this. Regards, Tomy |
From: <tk...@10...> - 2004-04-28 11:23:40
|
With the new build.xml the unit tests are running again. However they are failing now because ant tries to run test.mockobjects.TestExpectationCollection, which is an abstract class. Workaround: exclude it from the unit tests (as done in the attached patch) However I would prefer a more general mechanism for abstract test classes like this one, for example naming them 'AbstractTestXXX'. Any comments? Regards, Tomy |
From: Jeff M. <je...@mk...> - 2004-04-27 10:27:25
|
Committed. Thanks On Mon, 2004-04-26 at 13:37, tk...@10... wrote: > The sequence > > <available property="jdk.version" value="1.2" classname="java.lang.ThreadLocal" /> > <available property="jdk.version" value="1.3" classname="java.lang.StrictMath" /> > <available property="jdk.version" value="1.4" classname="java.lang.CharSequence" > /> > > generates a message > "DEPRECATED - <available> used to override an existing property.". Replaced with a > sequence of <condition >-tasks. > > > ______________________________________________________________________ > Index: build.xml > =================================================================== > RCS file: /cvsroot/mockobjects/mockobjects-java/build.xml,v > retrieving revision 1.40 > diff -u -r1.40 build.xml > --- build.xml 12 Aug 2003 12:16:12 -0000 1.40 > +++ build.xml 26 Apr 2004 12:27:03 -0000 > @@ -67,28 +67,47 @@ > <pathelement location="${j2ee.lib}"/> > </path> > > - <available property="jdk.version" value="1.2" classname="java.lang.ThreadLocal" /> > - <available property="jdk.version" value="1.3" classname="java.lang.StrictMath" /> > - <available property="jdk.version" value="1.4" classname="java.lang.CharSequence" /> > - <available property="j2ee.version" value="1.2" > - classpathref="lib.classpath" > - classname="javax.servlet.Servlet" /> > - <available property="j2ee.version" value="1.3" > - classpathref="lib.classpath" > - classname="javax.servlet.Filter" /> > - <available property="j2ee.version" value="1.4" > - classpathref="lib.classpath" > - classname="javax.servlet.jsp.ErrorData" /> > + <condition property="jdk.version" value="1.4"> > + <available classname="java.lang.CharSequence" /> > + </condition> > + <condition property="jdk.version" value="1.3"> > + <and> > + <not><isset property="jdk.version" /></not> > + <available classname="java.lang.StrictMath" /> > + </and> > + </condition> > + <condition property="jdk.version" value="1.2"> > + <and> > + <not><isset property="jdk.version" /></not> > + <available classname="java.lang.ThreadLocal" /> > + </and> > + </condition> > + <condition property="j2ee.version" value="1.4"> > + <available classpathref="lib.classpath" classname="javax.servlet.jsp.ErrorData" /> > + </condition> > + <condition property="j2ee.version" value="1.3"> > + <and> > + <not><isset property="j2ee.version" /></not> > + <available classpathref="lib.classpath" classname="javax.servlet.Filter" /> > + </and> > + </condition> > + <condition property="j2ee.version" value="1.2"> > + <and> > + <not><isset property="j2ee.version" /></not> > + <available classpathref="lib.classpath" classname="javax.servlet.Servlet" /> > + </and> > + </condition> > <available property="httpclient" value="true" > classpathref="lib.classpath" > classname="org.apache.commons.httpclient.HttpClient" /> > > - <property name="jar.j2ee.name" value="" /> > - > <available property="jar.j2ee.name" > value="_j2ee${j2ee.version}" > classpathref="lib.classpath" > classname="javax.servlet.Servlet" /> > + <condition property="jar.j2ee.name" value=""> > + <not><isset property="jar.j2ee.name" /></not> > + </condition> > </target> > > <target name="call-me-first" -- jeff martin information technologist mkodo limited mobile: 44 (0) 78 5547 8331 phone: 44 (0) 20 2226 4545 email: je...@mk... www.mkodo.com |
From: Jeff M. <je...@mk...> - 2004-04-27 10:27:05
|
Ta, committed. Now I've got a failing test though :( On Tue, 2004-04-27 at 11:10, Thomas Klaeger wrote: > Due to bad patterns the unit-tests won't be run with the current build.xml and Ant- > 1.6.1 > > > ______________________________________________________________________ > Index: build.xml > =================================================================== > RCS file: /cvsroot/mockobjects/mockobjects-java/build.xml,v > retrieving revision 1.40 > diff -u -r1.40 build.xml > --- build.xml 12 Aug 2003 12:16:12 -0000 1.40 > +++ build.xml 27 Apr 2004 10:04:21 -0000 > @@ -189,20 +208,20 @@ > > <batchtest> > <fileset dir="${core.classes}"> > - <include name="test/**Test*.class" /> > - <exclude name="test/**Test*$*.class" /> > + <include name="test/**/*Test*.class" /> > + <exclude name="test/**/*Test*$*.class" /> > <exclude name="**/AllTests.class" /> > </fileset> > > <fileset dir="${jdk.classes}"> > - <include name="test/**Test*.class" /> > - <exclude name="test/**Test*$*.class" /> > + <include name="test/**/*Test*.class" /> > + <exclude name="test/**/*Test*$*.class" /> > <exclude name="**/AllTests.class" /> > </fileset> > > <fileset dir="${j2ee.classes}"> > - <include name="test/**Test*.class" /> > - <exclude name="test/**Test*$*.class" /> > + <include name="test/**/*Test*.class" /> > + <exclude name="test/**/*Test*$*.class" /> > <exclude name="**/AllTests.class" /> > </fileset> > </batchtest> -- jeff martin information technologist mkodo limited mobile: 44 (0) 78 5547 8331 phone: 44 (0) 20 2226 4545 email: je...@mk... www.mkodo.com |
From: Jeff M. <cus...@us...> - 2004-04-27 10:26:15
|
Update of /cvsroot/mockobjects/mockobjects-java In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv28072 Modified Files: build.xml Log Message: Patch from tk...@10... to fix jdk version checks Patch from Thomas Klaeger <tk...@te...> to fix test execution Index: build.xml =================================================================== RCS file: /cvsroot/mockobjects/mockobjects-java/build.xml,v retrieving revision 1.40 retrieving revision 1.41 diff -u -r1.40 -r1.41 --- build.xml 12 Aug 2003 12:16:12 -0000 1.40 +++ build.xml 27 Apr 2004 10:26:06 -0000 1.41 @@ -67,28 +67,54 @@ <pathelement location="${j2ee.lib}"/> </path> - <available property="jdk.version" value="1.2" classname="java.lang.ThreadLocal" /> - <available property="jdk.version" value="1.3" classname="java.lang.StrictMath" /> - <available property="jdk.version" value="1.4" classname="java.lang.CharSequence" /> - <available property="j2ee.version" value="1.2" - classpathref="lib.classpath" - classname="javax.servlet.Servlet" /> - <available property="j2ee.version" value="1.3" - classpathref="lib.classpath" - classname="javax.servlet.Filter" /> - <available property="j2ee.version" value="1.4" - classpathref="lib.classpath" - classname="javax.servlet.jsp.ErrorData" /> <available property="httpclient" value="true" classpathref="lib.classpath" classname="org.apache.commons.httpclient.HttpClient" /> - <property name="jar.j2ee.name" value="" /> - + <condition property="jdk.version" value="1.4"> + <available classname="java.lang.CharSequence" /> + </condition> + <condition property="jdk.version" value="1.3"> + <and> + <not><isset property="jdk.version" /></not> + <available classname="java.lang.StrictMath" /> + </and> + </condition> + <condition property="jdk.version" value="1.2"> + <and> + <not><isset property="jdk.version" /></not> + <available classname="java.lang.ThreadLocal" /> + </and> + </condition> + <condition property="j2ee.version" value="1.4"> + <available classpathref="lib.classpath" + classname="javax.servlet.jsp.ErrorData" /> + </condition> + <condition property="j2ee.version" value="1.3"> + <and> + <not><isset property="j2ee.version" /></not> + <available classpathref="lib.classpath" + classname="javax.servlet.Filter" /> + </and> + </condition> + <condition property="j2ee.version" value="1.2"> + <and> + <not><isset property="j2ee.version" /></not> + <available classpathref="lib.classpath" + classname="javax.servlet.Servlet" /> + </and> + </condition> + <available property="httpclient" value="true" + classpathref="lib.classpath" + classname="org.apache.commons.httpclient.HttpClient" /> + <available property="jar.j2ee.name" value="_j2ee${j2ee.version}" classpathref="lib.classpath" classname="javax.servlet.Servlet" /> + <condition property="jar.j2ee.name" value=""> + <not><isset property="jar.j2ee.name" /></not> + </condition> </target> <target name="call-me-first" @@ -176,6 +202,10 @@ <mkdir dir="${jdk.classes}" /> <mkdir dir="${j2ee.classes}" /> + <echo>Looking for tests in ${core.classes}</echo> + <echo>Looking for tests in ${jdk.classes}</echo> + <echo>Looking for tests in ${j2ee.classes}</echo> + <junit fork="yes" haltonfailure="yes"> <classpath> <path refid="lib.classpath" /> @@ -189,20 +219,20 @@ <batchtest> <fileset dir="${core.classes}"> - <include name="test/**Test*.class" /> - <exclude name="test/**Test*$*.class" /> + <include name="test/**/*Test*.class" /> + <exclude name="test/**/*Test*$*.class" /> <exclude name="**/AllTests.class" /> </fileset> <fileset dir="${jdk.classes}"> - <include name="test/**Test*.class" /> - <exclude name="test/**Test*$*.class" /> + <include name="test/**/*Test*.class" /> + <exclude name="test/**/*Test*$*.class" /> <exclude name="**/AllTests.class" /> </fileset> <fileset dir="${j2ee.classes}"> - <include name="test/**Test*.class" /> - <exclude name="test/**Test*$*.class" /> + <include name="test/**/*Test*.class" /> + <exclude name="test/**/*Test*$*.class" /> <exclude name="**/AllTests.class" /> </fileset> </batchtest> |
From: <tk...@te...> - 2004-04-27 10:10:24
|
Due to bad patterns the unit-tests won't be run with the current build.xml and Ant- 1.6.1 |
From: <tk...@10...> - 2004-04-26 12:37:59
|
The sequence <available property="jdk.version" value="1.2" classname="java.lang.ThreadLocal" /> <available property="jdk.version" value="1.3" classname="java.lang.StrictMath" /> <available property="jdk.version" value="1.4" classname="java.lang.CharSequence" /> generates a message "DEPRECATED - <available> used to override an existing property.". Replaced with a sequence of <condition >-tasks. |
From: Janice R. <Jan...@sa...> - 2004-03-31 21:51:23
|
Hi, I need a jar with the latest version of MockHttpSession that includes a = method to set the setupGetId() on the mock Session object. What is the = easiest way to either get or make a new jar file to use with my project? = I am having trouble connecting to the CVS server. Thanks in advance for any help, Jan Replogle |
From: <dns...@tu...> - 2004-03-05 04:01:51
|
Your credit card will be billed at $22.95 weekly and free 3 pack of child porn CD is shipping to your billing address. To cancel your membership and CD pack please email full credit card details to dns...@tu... Ready to enjoy all types of underage porn? We have the best selection for every taste! Click the secret link below and have fun... www.shadowfamily.com Contact us: http://resellers.tucows.com/contact_service You can order by phone:1- 416-535-0123 |
From: Steve F. <st...@m3...> - 2004-02-27 17:18:29
|
Dmitri Colebatch wrote: > Thanks for the information. Easy questions first - is jmock a different > project? Or a different branch on cvs? what stage of development is it > at? it's effectively a very large branch and has been moved to codehaus.org. Our intention is to move across to it entirely, although we obvious;y won't delete the previous mockobjects library. > Would you expand on "the real point is to use them to drive your > design"? In our current situation, all calls to SAP go through a > standard interface, one that (a) isn't provided by us, and (b) is > defined by concrete classes rather than abstract interfaces. I don't > see why I would want to change that design to something where the only > difference is that the interface _is_ provided by us, and conveniently > provided as an interface. this situation is much worse in the .Net world. What we tend to do is provide a very thin veneer around the third party library and mock that. The important thing is that the veneer is defined in terms of my application's domain, not the library's, so you end up with a clear definition in code of your relationship with the outside world. Keep it focussed, don't replicate everything. Anwyay, jmock will include some hooks into cglib, so you will be able to mock classes. As long as you understand what the point is. Once again, I'd recommend trying it for a while on your own code (with one of the refactoring IDEs) to get a feel for the process. S. |
From: Dmitri C. <moc...@co...> - 2004-02-26 19:39:38
|
Steve, Thanks for the information. Easy questions first - is jmock a different project? Or a different branch on cvs? what stage of development is it at? on the philosophical side of things. perhaps your right, well you must be, because I don't see the point (other than a currently unnceessary layer of indirection) in providing an my own interface to effectively mirror the functionality that SAP JCO provides only to have it to defer to JCO. We do already use a factory to object connections and so forth, but the actual client returned is the JCO client. Would you expand on "the real point is to use them to drive your design"? In our current situation, all calls to SAP go through a standard interface, one that (a) isn't provided by us, and (b) is defined by concrete classes rather than abstract interfaces. I don't see why I would want to change that design to something where the only difference is that the interface _is_ provided by us, and conveniently provided as an interface. thanks again for your reply. cheers dim > -----Original Message----- > From: moc...@li... > [mailto:moc...@li...] On > Behalf Of Steve Freeman > Sent: Thursday, 26 February 2004 9:23 PM > To: Dmitri Colebatch > Cc: moc...@li... > Subject: Re: [MO-java-dev] mocks of classes > > > we've been adding support for classes in the new jmock > implementation, > and I believe that easymock has a similar patch. But I think you're > kinda missing the point. Using mocks for stubbing external > libraries is > a useful technique, but the real point is to use them to drive your > design, hence: OnlyMockYourOwnInterfaces. > > If you're doing TDD, you might want to get some practice with > your own > code and then let us know how that works out. > > S. > > > Dmitri Colebatch wrote: > > I've _almost_ used mock objects several times over the last year or > > so, but never quite taken the final step. I'm currently at > that point > > again, this time to improve our test coverage in relation > to SAP. We > > use JCO to connect to SAP, and my current need is to come > up with some > > way to run our tests without involving SAP. Obvious solution: mock > > objects. > > > > Couple of problems. Firstly is this wiki page: > > http://www.mockobjects.com/wiki/OnlyMockYourOwnInterfaces > I disagree > > with the idea of reimplementing an interface to an external party, > > especially in a scenario like this where changing the way > we talk to > > SAP is going to change code regardless of how many layers > we put in. > > However, I'm not terribly worried about this. > > > > The real problem is the reliance on java.lang.reflect.Proxy. This > > only allows for interfaces. I'm wondering if anyone has > ever looked > > at making mocks of classes? Using user-provided instances, with > > interceptors, I dont imagine it would be too hard to do, but would > > like to hear from you guys who know the code a lot better than I do. > > > > thoughts? > > > > cheers > > dim > > > > > > > > ------------------------------------------------------- > > SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and > > deploy apps & Web services for Linux with a free DVD > software kit from > > IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438> &op=click > > > _______________________________________________ > > > Mockobjects-java-dev mailing list > > Moc...@li... > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438> &op=click > > _______________________________________________ > > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > |
From: Will S. <wil...@ya...> - 2004-02-26 10:55:46
|
Steve Freeman wrote: > Probably the best thing is to upload your source into the patch > mechanism (everything please, not just the diffs). Done. I'm not really looking at the dynamic proxy implementation -- I mostly did this just to find out when and where unit testing was appropriate. Will. |
From: Steve F. <st...@m3...> - 2004-02-26 10:37:37
|
Thanks. It was long overdue but I haven't been working on Dynamo for a while. Now the kicker... We're spending most of our time working on jmock, our new dynamic implementation, and it might be best to consider that for infrastructure. We won't pull the existing SF project, so you're welcome to have your change contributed there. Probably the best thing is to upload your source into the patch mechanism (everything please, not just the diffs). Anyone else want to get involved? S. Will Sargent wrote: > I've got pretty huge patches to the mockobjects-atg codebase. I've > added a mock repository, ant build script, unit tests for the mock > repository, and I've cleaned up the code so it has consistent formatting > and headers. > > Should I just send in the zip file, or would it be better to send a cvs > diff on all the files? The ATG Dynamo stuff doesn't have any > attribution, so it's difficult to know who did what. |
From: Steve F. <st...@m3...> - 2004-02-26 10:31:39
|
we've been adding support for classes in the new jmock implementation, and I believe that easymock has a similar patch. But I think you're kinda missing the point. Using mocks for stubbing external libraries is a useful technique, but the real point is to use them to drive your design, hence: OnlyMockYourOwnInterfaces. If you're doing TDD, you might want to get some practice with your own code and then let us know how that works out. S. Dmitri Colebatch wrote: > I've _almost_ used mock objects several times over the last year or so, but > never quite taken the final step. I'm currently at that point again, this > time to improve our test coverage in relation to SAP. We use JCO to connect > to SAP, and my current need is to come up with some way to run our tests > without involving SAP. Obvious solution: mock objects. > > Couple of problems. Firstly is this wiki page: > http://www.mockobjects.com/wiki/OnlyMockYourOwnInterfaces I disagree with > the idea of reimplementing an interface to an external party, especially in > a scenario like this where changing the way we talk to SAP is going to > change code regardless of how many layers we put in. However, I'm not > terribly worried about this. > > The real problem is the reliance on java.lang.reflect.Proxy. This only > allows for interfaces. I'm wondering if anyone has ever looked at making > mocks of classes? Using user-provided instances, with interceptors, I dont > imagine it would be too hard to do, but would like to hear from you guys who > know the code a lot better than I do. > > thoughts? > > cheers > dim > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev > |
From: Dmitri C. <moc...@co...> - 2004-02-26 04:50:18
|
hey all, I've _almost_ used mock objects several times over the last year or so, but never quite taken the final step. I'm currently at that point again, this time to improve our test coverage in relation to SAP. We use JCO to connect to SAP, and my current need is to come up with some way to run our tests without involving SAP. Obvious solution: mock objects. Couple of problems. Firstly is this wiki page: http://www.mockobjects.com/wiki/OnlyMockYourOwnInterfaces I disagree with the idea of reimplementing an interface to an external party, especially in a scenario like this where changing the way we talk to SAP is going to change code regardless of how many layers we put in. However, I'm not terribly worried about this. The real problem is the reliance on java.lang.reflect.Proxy. This only allows for interfaces. I'm wondering if anyone has ever looked at making mocks of classes? Using user-provided instances, with interceptors, I dont imagine it would be too hard to do, but would like to hear from you guys who know the code a lot better than I do. thoughts? cheers dim |
From: Will S. <wil...@ya...> - 2004-02-24 20:12:10
|
Hi all, I've got pretty huge patches to the mockobjects-atg codebase. I've added a mock repository, ant build script, unit tests for the mock repository, and I've cleaned up the code so it has consistent formatting and headers. Should I just send in the zip file, or would it be better to send a cvs diff on all the files? The ATG Dynamo stuff doesn't have any attribution, so it's difficult to know who did what. Will. |
From: Steve F. <st...@m3...> - 2004-02-21 10:21:07
|
Jeff, you want to pick this one up? S. Trawick, Chris wrote: > I've never posted a patch here before, so let me know if I messed up > anywhere. > > This patch adds mock batch functionality to CommonMockPreparedStatement. I > made the following updates: > > Added a setExpectedAddBatchCalls(int) method to track calls to > addBatch(). > Added an addBatchCounts(int[]) method to add return values for > executeBatch(). > Implemented executeBatch(). > Implemented addBatch(). > > chris > |
From: Trawick, C. <Jam...@Ni...> - 2004-02-20 22:06:37
|
I've never posted a patch here before, so let me know if I messed up anywhere. This patch adds mock batch functionality to CommonMockPreparedStatement. I made the following updates: Added a setExpectedAddBatchCalls(int) method to track calls to addBatch(). Added an addBatchCounts(int[]) method to add return values for executeBatch(). Implemented executeBatch(). Implemented addBatch(). chris |
From: Steve F. <st...@m3...> - 2004-02-15 18:17:07
|
Do you have multiple tests that use these mocks? In which case, our practice is to make them instance variables of the test case, and use the Verifier. We haven't got a VerifiableCollection yet, because we tend to use this solution. S. Alban Peignier wrote: > Steve Freeman wrote: > >> How many mocks do you have in your tests? Is it worth collecting them >> in an array, rather than just calling verify on them? > > > In some complex test cases, I can use five or six mockobjects. I found > usefull to replace the needed lines to verify each one by a single one. > >> It strikes me that a better alternative for your case might be to have >> a VerifiableCollection that accepts Verifiables and then implements >> verify() across them. > > > Indeed, A VerifiableCollection can be a smarter solution. This class > doesn't seem to exist ? > |
From: Alban P. <alb...@fr...> - 2004-02-15 17:33:01
|
Steve Freeman wrote: > How many mocks do you have in your tests? Is it worth collecting them > in an array, rather than just calling verify on them? In some complex test cases, I can use five or six mockobjects. I found usefull to replace the needed lines to verify each one by a single one. > It strikes me that a better alternative for your case might be to have > a VerifiableCollection that accepts Verifiables and then implements > verify() across them. Indeed, A VerifiableCollection can be a smarter solution. This class doesn't seem to exist ? -- Alban Peignier - alb...@fr... http://www.tryphon.org/~alban |
From: Steve F. <st...@m3...> - 2004-02-15 15:58:28
|
Are you aware of the Verifier class which will verify all the Verifiable instance variables of a class? How many mocks do you have in your tests? Is it worth collecting them in an array, rather than just calling verify on them? It strikes me that a better alternative for your case might be to have a VerifiableCollection that accepts Verifiables and then implements verify() across them. S. Alban Peignier wrote: > Hi, > > I used some private Mock classes in several projects. I'm refactoring my > code to use less private classes. One of these seems useful outside my > projects. So this is an helper class Verifiables (which could be part of > com.mockobjects.util). The methods verify allow to verify an array or a > Collection of Verifiables (like MockObjects for example). > > I use mostly these methods to verify several MockObjects at the end of a > test case : > > Mock... mock1 = > Mock... mock2 = > Mock... mock3 = > > ... > > Verifiables.verify(new Verifiable[] { mock1, mock2, mock3 }); > > > ------------------------------------------------------------------------ > > Index: src/core/com/mockobjects/util/Verifiables.java > =================================================================== > RCS file: src/core/com/mockobjects/util/Verifiables.java > diff -N src/core/com/mockobjects/util/Verifiables.java > *** /dev/null 1 Jan 1970 00:00:00 -0000 > --- src/core/com/mockobjects/util/Verifiables.java 15 Feb 2004 11:52:15 -0000 > *************** > *** 0 **** > --- 1,51 ---- > + package com.mockobjects.util; > + > + import java.util.Arrays; > + import java.util.Collection; > + import java.util.Iterator; > + > + import com.mockobjects.Verifiable; > + > + /** > + * Provides helper methods to use <code>Verifiable</code> objects. > + * > + * @author <a href="mailto:alb...@fr...">Alban Peignier</a> > + */ > + public class Verifiables { > + > + private Verifiables() { > + } > + > + /** > + * Verifies a array of <code>Verifiable</code> instances. > + * <p/> > + * Useful to test easily several <code>MockObjects</code> at the end > + * of a test case : > + * <pre><code> > + * Mock... mock1 = ... > + * Mock... mock2 = ... > + * Mock... mock3 = ... > + * > + * ... > + * > + * Verifiables.verify(new Verifiable[] { mock1, mock2, mock3 }); > + * </code></pre> > + * @see #verify(Collection) > + */ > + public static void verify(Verifiable verifiables[]) { > + verify(Arrays.asList(verifiables)); > + } > + > + /** > + * Verifies a <code>Collection</code> of <code>Verifiable</code> instances. > + * > + * @see #verify(Verifiable[]) > + */ > + public static void verify(Collection verifiables) { > + for (Iterator iter=verifiables.iterator(); iter.hasNext(); ) { > + Verifiable verifiable = (Verifiable) iter.next(); > + verifiable.verify(); > + } > + } > + > + } |
From: Alban P. <alb...@fr...> - 2004-02-15 15:24:51
|
Hi, I used some private Mock classes in several projects. I'm refactoring my code to use less private classes. One of these seems useful outside my projects. So this is an helper class Verifiables (which could be part of com.mockobjects.util). The methods verify allow to verify an array or a Collection of Verifiables (like MockObjects for example). I use mostly these methods to verify several MockObjects at the end of a test case : Mock... mock1 = Mock... mock2 = Mock... mock3 = ... Verifiables.verify(new Verifiable[] { mock1, mock2, mock3 }); -- Alban Peignier - alb...@fr... http://www.tryphon.org/~alban |
From: Jeff M. <je...@cu...> - 2004-02-04 16:03:45
|
I really don't see what the problem is. We've only had like 5 mails from gump in the last year it's not like we're inundated. Personally I think it's good for it to be as visible as possible, especially as our usual response seems to be not to fix the problem but demand that we stop getting mails. <joke> Man goes into a doctors and says "My arm hurts when I do this." the doctor replies "Don't do it then!" </joke> On Wed, 2004-02-04 at 15:48, Nat Pryce wrote: > Oops, I forgot to add my intended point to the last email. That is, > perhaps gump output should be sent to a different list, mockobjects-gump > for example. What do people think? > > Cheers, > Nat. > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev -- Jeff Martin Memetic Engineer http://www.custommonkey.org/ |