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: Barry K. <bk...@in...> - 2002-11-21 17:09:31
|
I have the following test snippet: Mock mockConnection = new Mock(Connection.class); Mock mockSelectStatement = new Mock(PreparedStatement.class); Mock mockUpdateStatement = new Mock(PreparedStatement.class); CallSequence prepareStatementCalls = new CallSequence(); prepareStatementCalls.expectReturn(HighLowIdentityGenerator.SELECT_NEXT_BLOCK_STATEMENT, mockSelectStatement.proxy()); prepareStatementCalls.expectReturn(HighLowIdentityGenerator.UPDATE_NEXT_BLOCK_STATEMENT, mockUpdateStatement.proxy()); mockConnection.expect("prepareStatement", prepareStatementCalls); mockSelectStatement.expectAndReturn("executeQuery", null); mockUpdateStatement.expectVoid("execute"); generator.setIdentity(mockDatabaseContext, object); mockConnection.verify(); // This succeeds, I would expect it fail prepareStatementCalls.verify(); // This fails, as I expect assertEquals(1, object.getId()); It seems that the MethodMap only checks that the method of the name was invoked, but does not take into account that the MockCall for that method was a CallSequence. Should MethodMap be delegating to MockCall for [part of?] its verify? -bk |
From: Jeff M. <cus...@us...> - 2002-11-20 19:10:28
|
Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/mail In directory sc8-pr-cvs1:/tmp/cvs-serv1062/src/j2ee/common/com/mockobjects/mail Modified Files: MockMessage.java Log Message: Implmented setContent method Index: MockMessage.java =================================================================== RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/mail/MockMessage.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- MockMessage.java 19 Jun 2002 15:26:21 -0000 1.1 +++ MockMessage.java 20 Nov 2002 19:10:23 -0000 1.2 @@ -198,7 +198,7 @@ } public void setContent(Multipart multipart) throws MessagingException { - notImplemented(); + myContent.setActual(multipart); } public void writeTo(OutputStream stream) throws IOException, MessagingException { |
From: Jeff M. <cus...@us...> - 2002-11-20 19:09:03
|
Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet In directory sc8-pr-cvs1:/tmp/cvs-serv32623/src/j2ee/1.3/com/mockobjects/servlet Modified Files: MockHttpServletResponse.java Log Message: Changed old fail calls to be notImplemented Added support to setContentLength Index: MockHttpServletResponse.java =================================================================== RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet/MockHttpServletResponse.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- MockHttpServletResponse.java 23 Feb 2002 18:50:35 -0000 1.1 +++ MockHttpServletResponse.java 20 Nov 2002 19:08:58 -0000 1.2 @@ -1,138 +1,177 @@ package com.mockobjects.servlet; -import java.io.*; -import javax.servlet.*; -import javax.servlet.http.*; -import junit.framework.Assert; import com.mockobjects.*; -public class MockHttpServletResponse extends MockObject implements HttpServletResponse, Verifiable { - private ExpectationList myContentTypes = new ExpectationList("MockHttpServletResponse.setContentType"); - private ExpectationList myHeaders = new ExpectationList("MockHttpServletResponse.setHeader"); - private ExpectationCounter mySetStatusCalls = new ExpectationCounter("MockHttpServletResponse.setStatus"); - private ExpectationList myRedirects = new ExpectationList("MockHttpServletResponse.sendRedirect"); - private ServletOutputStream myOutputStream = new MockServletOutputStream(); - private ExpectationValue myErrorCode = new ExpectationValue("MockHttpServletResponse.sendError"); - private ExpectationValue myErrorMessage = new ExpectationValue("MockHttpServletResponse.sendError"); +import javax.servlet.ServletOutputStream; +import javax.servlet.http.Cookie; +import javax.servlet.http.HttpServletResponse; +import java.io.IOException; +import java.io.PrintWriter; +import java.util.Locale; + +public class MockHttpServletResponse extends MockObject + implements HttpServletResponse { + + private final ExpectationList myContentTypes = + new ExpectationList("MockHttpServletResponse.setContentType"); + private final ExpectationList myHeaders = + new ExpectationList("MockHttpServletResponse.setHeader"); + private final ExpectationCounter mySetStatusCalls = + new ExpectationCounter("MockHttpServletResponse.setStatus"); + private final ExpectationList myRedirects = + new ExpectationList("MockHttpServletResponse.sendRedirect"); + private MockServletOutputStream myOutputStream = + new MockServletOutputStream(); + private final ExpectationValue myErrorCode = + new ExpectationValue("MockHttpServletResponse.sendError"); + private final ExpectationValue myErrorMessage = + new ExpectationValue("MockHttpServletResponse.sendError"); + private final ExpectationValue length = new ExpectationValue("MockHttpServletResponse.length"); /** - * MockHttpServletResponse constructor comment. + * Not Implemented */ - public MockHttpServletResponse() { - super(); - } - - public void addCookie(javax.servlet.http.Cookie arg1) { - fail("Not implemented"); + public void addCookie(Cookie arg1) { + notImplemented(); } /** - * addDateHeader method comment. + * Not Implemented */ - public void addDateHeader(java.lang.String arg1, long arg2) { + public void addDateHeader(String arg1, long arg2) { + notImplemented(); } /** - * addHeader method comment. + * Not Implemented */ - public void addHeader(java.lang.String arg1, java.lang.String arg2) { + public void addHeader(String arg1, String arg2) { + notImplemented(); } /** - * addIntHeader method comment. + * Not Implemented */ - public void addIntHeader(java.lang.String arg1, int arg2) { + public void addIntHeader(String arg1, int arg2) { + notImplemented(); } + /** + * Not Implemented + */ public boolean containsHeader(String arg1) { - fail("Not implemented"); + notImplemented(); return false; } + /** + * Not Implemented + */ public String encodeRedirectUrl(String arg1) { - fail("Not implemented"); + notImplemented(); return null; } + /** + * Not Implemented + */ public String encodeRedirectURL(String arg1) { - fail("Not implemented"); + notImplemented(); return null; } + /** + * Not Implemented + */ public String encodeUrl(String arg1) { - fail("Not implemented"); + notImplemented(); return null; } + /** + * Not Implemented + */ public String encodeURL(String arg1) { - fail("Not implemented"); + notImplemented(); return null; } /** - * flushBuffer method comment. + * Not Implemented */ public void flushBuffer() throws java.io.IOException { + notImplemented(); } /** - * getBufferSize method comment. + * Not Implemented */ public int getBufferSize() { + notImplemented(); return 0; } + /** + * Not Implemented + */ public String getCharacterEncoding() { - fail("Not implemented"); + notImplemented(); return null; } /** - * getLocale method comment. + * Not Implemented */ - public java.util.Locale getLocale() { + public Locale getLocale() { + notImplemented(); return null; } - public javax.servlet.ServletOutputStream getOutputStream() - throws java.io.IOException { + public ServletOutputStream getOutputStream() + throws IOException { return myOutputStream; } public String getOutputStreamContents() { - return ((MockServletOutputStream) myOutputStream).getContents(); + return myOutputStream.getContents(); } - public java.io.PrintWriter getWriter() throws java.io.IOException { + public PrintWriter getWriter() throws IOException { return new PrintWriter(myOutputStream, true); } /** - * isCommitted method comment. + * Not Implemented */ public boolean isCommitted() { + notImplemented(); return false; } /** - * reset method comment. + * Not Implemented */ public void reset() { + notImplemented(); } - public void resetBuffer(){ + /** + * Not Implemented + */ + public void resetBuffer() { + notImplemented(); } - public void setExpectedError(int anErrorCode){ + public void setExpectedError(int anErrorCode) { myErrorCode.setExpected(anErrorCode); } - public void setExpectedError(int anErrorCode, String anErrorMessage){ + public void setExpectedError(int anErrorCode, String anErrorMessage) { setExpectedError(anErrorCode); myErrorMessage.setExpected(anErrorMessage); } - public void setExpectedErrorNothing(){ + public void setExpectedErrorNothing() { myErrorCode.setExpectNothing(); myErrorMessage.setExpectNothing(); } @@ -142,7 +181,7 @@ } public void sendError(int anErrorCode, String anErrorMessage) - throws IOException { + throws IOException { sendError(anErrorCode); myErrorMessage.setActual(anErrorMessage); } @@ -152,21 +191,29 @@ } /** - * setBufferSize method comment. + * Not Implemented */ public void setBufferSize(int arg1) { + notImplemented(); + } + + public void setContentLength(int length) { + this.length.setActual(length); } - public void setContentLength(int arg1) { - fail("Not implemented"); + public void setExpectedContentLength(int length){ + this.length.setExpected(length); } public void setContentType(String contentType) { myContentTypes.addActual(contentType); } + /** + * Not Implemented + */ public void setDateHeader(String arg1, long arg2) { - fail("Not implemented"); + notImplemented(); } public void setExpectedContentType(String contentType) { @@ -189,25 +236,32 @@ myHeaders.addActual(new MapEntry(key, value)); } + /** + * Not Implemented + */ public void setIntHeader(String arg1, int arg2) { - Assert.fail("Not implemented"); + notImplemented(); } /** - * setLocale method comment. + * Not Implemented */ - public void setLocale(java.util.Locale arg1) { + public void setLocale(Locale arg1) { + notImplemented(); } public void setStatus(int status) { mySetStatusCalls.inc(); } + /** + * Not Implemented + */ public void setStatus(int arg1, String arg2) { - Assert.fail("Not implemented"); + notImplemented(); } - public void setupOutputStream(ServletOutputStream anOutputStream) { + public void setupOutputStream(MockServletOutputStream anOutputStream) { myOutputStream = anOutputStream; } } |
From: Barry K. <bk...@in...> - 2002-11-20 15:49:13
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body> Tim Mackinnon wrote:<br> <blockquote type=3D"cite" cite=3D"mid...@po..."> <title></title> <meta http-equiv=3D"Content-Type" content=3D"text/html; "> <meta content=3D"MSHTML 5.50.4919.2200" name=3D"GENERATOR"> <div><span class=3D"153461600-20112002"><font face=3D"Arial" color=3D"#0000ff" size=3D"2">I have been a silent lurker on this on= e - but there is a code smell here... using overloading of methods in this w= ay is a bad sign (it may ultimately be legitamate but there is a smell I h= ave encounterered in other java code).</font></span></div> <div><span class=3D"153461600-20112002"></span>=A0</div> <div><span class=3D"153461600-20112002"><font face=3D"Arial" color=3D"#0000ff" size=3D"2">If you want to avoid an if statment bu= t are relying on overloading to get this - </font></span></div> </blockquote> <br> The overloading has nothing to do with the avoidance of if-statements= , as I think I mentioned earlier.<br> <br> <blockquote type=3D"cite" cite=3D"mid...@po..."> <div><span class=3D"153461600-20112002"><font face=3D"Arial" color=3D"#0000ff" size=3D"2">there is an issue. </font></span><span class=3D"153461600-20112002"><font face=3D"Arial" color=3D"#0000ff" = size=3D"2">From a quick glance, this looks like a double dispatch pattern - the obje= ct you are passing in is a visitor, different objects call back using the d= ifferent method signatures -</font></span></div> </blockquote> <br> No, this is not a visitor. It is simply a multi-key lookup, in which = the clients know the keys, but are closed to the key values.<br> <br> <blockquote type=3D"cite" cite=3D"mid...@po..."> <div><span class=3D"153461600-20112002"><font face=3D"Arial" color=3D"#0000ff" size=3D"2"> this isn't polymorphic at all - you d= on't really gain anything from giving the same method name to=A0the two methods = as they are just differnt =A0(they have different paramaters anyway) - why n= ot be clearer and say getShorQuatity.... and getPositionQuatity (eg. diffe= rent names).</font></span></div> <div><span class=3D"153461600-20112002"></span>=A0</div> <div><span class=3D"153461600-20112002"><font face=3D"Arial" color=3D"#0000ff" size=3D"2">If you want polymorphism - getQuatity = should have the same parameter with some other object that has the details requi= red. This is often the smell - you are missing some other object (which i= s the single paramater)- your tests may be telling you this???</font></spa= n></div> </blockquote> <br> I've made no claim of polymorphism (If I did it was in error). What I= did/do claim was the desire to eliminate the client from having to know the = key values, and invoke different methods depending on those values. <br> <br> The overloading is completely orthoginal to the issue of the client n= ot requiring ifs, and support for overloading in mocks. And of course no client ca= n act in a polymorphic manner with regard to the two overloaded methods as = they have different parameter types (maybe this is what you pointing out).= In fact, the same client does not use both methods. Yes, I could name th= e two methods differently (in the spirit of Effiel), but again that is a di= fferent topic from the support of overloaded methods in mocks.<br> =20 <blockquote type=3D"cite" cite=3D"mid...@po..."><sp= an class=3D"153461600-20112002"></span><font face=3D"Tahoma"></font> <div><font face=3D"Tahoma"><br> <font size=3D"2"><span class=3D"153461600-20112002"><font face=3D"A= rial" color=3D"#0000ff">If you were overloading with the same number of pa= rameters - is there something common in those parameters (ie some interface) = - if so the interaced parameters should be used and the mock would be si= mple.</font></span></font></font></div> </blockquote> <br> No. What is common is the intention: "get the position quantity".<br> <br> Thanks for the feedback Tim.<br> <blockquote type=3D"cite" cite=3D"mid...@po..."> <div><font face=3D"Tahoma"><font face=3D"Arial" color=3D"#0000ff" s= ize=3D"2"><span class=3D"153461600-20112002"></span></font></font></div> </blockquote> <br> <br> </body> </html> |
From: Tim M. <tim...@po...> - 2002-11-20 00:30:36
|
I have been a silent lurker on this one - but there is a code smell here... using overloading of methods in this way is a bad sign (it may ultimately be legitamate but there is a smell I have encounterered in other java code). If you want to avoid an if statment but are relying on overloading to get this - there is an issue. From a quick glance, this looks like a double dispatch pattern - the object you are passing in is a visitor, different objects call back using the different method signatures - this isn't polymorphic at all - you don't really gain anything from giving the same method name to the two methods as they are just differnt (they have different paramaters anyway) - why not be clearer and say getShorQuatity.... and getPositionQuatity (eg. different names). If you want polymorphism - getQuatity should have the same parameter with some other object that has the details required. This is often the smell - you are missing some other object (which is the single paramater)- your tests may be telling you this??? If you were overloading with the same number of parameters - is there something common in those parameters (ie some interface) - if so the interaced parameters should be used and the mock would be simple. Tim -----Original Message----- From: moc...@li... [mailto:moc...@li...]On Behalf Of Barry Kaplan Sent: 19 November 2002 16:22 To: Nat Pryce Cc: mockobjects dev Subject: Re: [MO-java-dev] dynamic mock cannot handle overloaded methods The class I have been using to learn mocksobjects: public interface Position { int getQuantity(PositionBucketType bucketType, PositionTimeType timeType); int getQuantity(LongShort longShort, CreditType creditType, PositionTimeType timeType); .... } Different components of our system know different aspects of a position. The two methods above allow each to access the quantities polymorphically without any ifs or switches. Java does not dispatch methods polymorphically based on runtime argument types. If your code is calling overloaded methods you don't need ifs and switches. I was not refering to polymorphism at the overloaded method level, but the ability to not have to do: int quantity if ( bla bla) { getLongCashOvernightQuantity(); else if (bla bla) { get ShortCashOvernightQuantity(); else if (bla bla) get LongMarginDaytradeQuantity(); else if (bla bla) ... (Remember, you asked why overloaded methods were necessary at the interface level. The above is why). ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Mockobjects-java-dev mailing list Moc...@li... https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.419 / Virus Database: 235 - Release Date: 13/11/2002 |
From: Barry K. <bk...@in...> - 2002-11-19 20:28:29
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> Nat Pryce wrote:<br> <blockquote type="cite" cite="mid...@ba..."> <pre wrap="">On Tue, 2002-11-19 at 17:30, Barry Kaplan wrote: </pre> <blockquote type="cite"> <pre wrap="">Nat Pryce wrote: </pre> <blockquote type="cite"> <pre wrap="">The Constraints do not have any knowledge of the class of the object being constraint, except for the IsInstanceOf constraint, which is a special case. </pre> </blockquote> <pre wrap="">But they have the object being constrained. The object knows its Class. Am I missing something? </pre> </blockquote> <pre wrap=""><!----> The MockCall object passes the method arguments to the constraints when it is called. Each constraint returns true if the argument that it is checking meets the constraint or false if it doesn't. If any constraint returns false, the MockCall throws an AssertionFailedError. </pre> </blockquote> Sorry, what I meant say was that MockCall has an object with which to do the comparison against the actual call arguments. From those objects we can get the class. But as you pointed out, some MockCall's take no object to compare with, because they do no comparison. For MockCall to resolve the actual call argument Class's, those MockCall's would need to take a Class as a psuedo comparison argument. A bit of a smell, I agree.<br> <br> -bk<br> <br> </body> </html> |
From: Barry K. <bk...@in...> - 2002-11-19 20:25:46
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> Nat Pryce wrote:<br> <blockquote type="cite" cite="mid...@ba..."> <pre wrap="">On Tue, 2002-11-19 at 16:54, Barry Kaplan wrote: </pre> <blockquote type="cite"> <pre wrap="">Nat Pryce wrote: </pre> <blockquote type="cite"> <pre wrap="">How do overloaded methods help you remove the if statements? </pre> </blockquote> <pre wrap="">Components of the system need to determine Position quantity based on the aspects Long/Short, Cash/Margin/etc, Daytrade/Overnight/etc. But for the most part, those components are closed to the actual values of these aspects -- they were constructed with the values. Those components do not even know what the values/subtypes of LongShort, etc are, but can use them to to lookup position quantities and perform their work. As the values/subtypes of LongShort etc are extended, the components are closed to those changes/extensions. I guess this description is kind of vague, but maybe it gets the point across (?). </pre> </blockquote> <pre wrap=""><!----> I'm still not sure why overloaded methods help avoid if statements, since to call the appropriate overloaded method your code must already have statically typed values to pass to the method. Therefore your code can just as easily call a method with a descriptive name as call a method with the same name as another method but different argument types.</pre> </blockquote> <br> Its not the overloaded methods per se. Its the parameterized getQuantity. It just so happens that getQuantity provides two sets of aspects on which to obtain the value. Thus I need to mock both methods.<br> <br> -bk<br> <br> </body> </html> |
From: Nat P. <nat...@b1...> - 2002-11-19 18:24:07
|
On Tue, 2002-11-19 at 17:23, Barry Kaplan wrote: > Nat Pryce wrote: > > On Tue, 2002-11-19 at 16:59, Barry Kaplan wrote: > > > > > That will certainly work. But I would rather not allow for the mistake > > > of a mismatch between class and object if possible. > > > > > > > That would be checked when setupXXX or expectXXX is called. Any > > mismatch would result in an AssertionFailedError being thrown at that > > point. Mismatch at invocation time would be prevented by Java's type > > system. > But it still requires the programmer to specify the same information > in two places. > > > That is why I wanted > > > Constraint to be responsible for providing the Class as it already knows > > > (once-and-only-once). > > > In my opinion it is only specified once. The constraints check object *values* and can assume that the types are already checked by the language. The only time you would need to specify types explicitly is to disambiguate overloaded methods. Cheers, Nat. -- Nat Pryce <nat...@b1...> B13media |
From: Nat P. <nat...@b1...> - 2002-11-19 18:22:08
|
On Tue, 2002-11-19 at 17:30, Barry Kaplan wrote: > Nat Pryce wrote: > > The Constraints do not have any knowledge of the class of the object > > being constraint, except for the IsInstanceOf constraint, which is a > > special case. > But they have the object being constrained. The object knows its > Class. Am I missing something? The MockCall object passes the method arguments to the constraints when it is called. Each constraint returns true if the argument that it is checking meets the constraint or false if it doesn't. If any constraint returns false, the MockCall throws an AssertionFailedError. Cheers, Nat. -- Nat Pryce <nat...@b1...> B13media |
From: Barry K. <bk...@in...> - 2002-11-19 17:25:08
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> Nat Pryce wrote:<br> <blockquote type="cite" cite="mid...@ba..."> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> I'm confused about this: * MockCall *is* part of the public interface. </pre> </blockquote> <pre wrap="">Adding a method to MockCall will not break existing code. (But it will make creating anonymous inners harder, as you point out below.) </pre> </blockquote> <pre wrap=""><!----> It will break all code that defines classes that implement MockCall.</pre> </blockquote> <br> Whoops. I was thinking MockCall was a class.<br> <blockquote type="cite" cite="mid...@ba..."> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">* Constraints do not specify the expected argument types, so I don't see how querying for a list of constraints will help you overload on argument types. </pre> </blockquote> <pre wrap="">Not the constraints, but the Class of the object being constrained. </pre> </blockquote> <pre wrap=""><!----> The Constraints do not have any knowledge of the class of the object being constraint, except for the IsInstanceOf constraint, which is a special case.</pre> </blockquote> But they have the object being constrained. The object knows its Class. Am I missing something?<br> <br> -bk<br> <br> </body> </html> |
From: Barry K. <bk...@in...> - 2002-11-19 17:18:43
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> Nat Pryce wrote:<br> <blockquote type="cite" cite="mid...@ba..."> <pre wrap="">On Tue, 2002-11-19 at 16:59, Barry Kaplan wrote: </pre> <blockquote type="cite"> <pre wrap="">That will certainly work. But I would rather not allow for the mistake of a mismatch between class and object if possible. </pre> </blockquote> <pre wrap=""><!----> That would be checked when setupXXX or expectXXX is called. Any mismatch would result in an AssertionFailedError being thrown at that point. Mismatch at invocation time would be prevented by Java's type system.</pre> </blockquote> But it still requires the programmer to specify the same information in two places.<br> <blockquote type="cite" cite="mid...@ba..."> <blockquote type="cite"> <pre wrap="">That is why I wanted Constraint to be responsible for providing the Class as it already knows (once-and-only-once). </pre> </blockquote> <pre wrap=""><!----> Constraints are meant to provide flexibility. E.g. there is an IsAnything constraint for when your test doesn't care about actual values.</pre> </blockquote> Could not the IsAnything take a Class as an argument? Or are you using IsAnything to cover multiple methods at once?<br> <blockquote type="cite" cite="mid...@ba..."> <pre wrap=""> Also, Constraints are invoked *after* the static type system and runtime type checking in the Reflection API has checked that types are correct, so there is no need for Constraints to specify more about types than is actually needed for the test.</pre> </blockquote> I'm not purposing invoking the constraint, but determining the Class's of the objects which are being constrained, using that to determine a specific Method. The purpose being to use Method as the key in MethodMap. <br> <br> But you have exhausted my knowlege of the dynamic mock code. I need to write tests and modify the dynamic mocks to see my actual requiremetns and the forces on the dynmic mock design.<br> <br> And thanks much for the feedback! It is helping me very much.<br> <br> -bk<br> <br> </body> </html> |
From: Nat P. <nat...@b1...> - 2002-11-19 17:10:16
|
On Tue, 2002-11-19 at 16:59, Barry Kaplan wrote: > > > That will certainly work. But I would rather not allow for the mistake > of a mismatch between class and object if possible. That would be checked when setupXXX or expectXXX is called. Any mismatch would result in an AssertionFailedError being thrown at that point. Mismatch at invocation time would be prevented by Java's type system. > That is why I wanted > Constraint to be responsible for providing the Class as it already knows > (once-and-only-once). Constraints are meant to provide flexibility. E.g. there is an IsAnything constraint for when your test doesn't care about actual values. Also, Constraints are invoked *after* the static type system and runtime type checking in the Reflection API has checked that types are correct, so there is no need for Constraints to specify more about types than is actually needed for the test. Cheers, Nat. -- Nat Pryce <nat...@b1...> B13media |
From: Barry K. <bk...@in...> - 2002-11-19 17:07:00
|
Nat Pryce wrote: >Instead of discussing how to *implement* overloaded mocked methods, lets >work out how tests will specify overloaded mocked methods, and go from >there. > Agreed. That's why I have to start converting our tests and see what the code (tests) tells me. > >What do you think of my API suggestion? > (see other message) -bk |
From: Nat P. <nat...@b1...> - 2002-11-19 16:56:42
|
Instead of discussing how to *implement* overloaded mocked methods, lets work out how tests will specify overloaded mocked methods, and go from there. What do you think of my API suggestion? Cheers, Nat. On Tue, 2002-11-19 at 16:43, Barry Kaplan wrote: > > > > > >I'm confused about this: > > > >* MockCall *is* part of the public interface. > > > Adding a method to MockCall will not break existing code. (But it will > make creating anonymous inners harder, as you point out below.) It will break all code that defines classes that implement MockCall. The MockCall interface is part of the Mock API, because of the methods setup(name,MockCall) and expect(name,MockCall). > >* Constraints do not specify the expected argument types, so I don't see > >how querying for a list of constraints will help you overload on > >argument types. > > > Not the constraints, but the Class of the object being constrained. The Constraints do not have any knowledge of the class of the object being constraint, except for the IsInstanceOf constraint, which is a special case. > >* MockCall objects do not have to have Constraints -- they can check > >argument values in any way they choose. For example, I have tests that > >uses anonymous inner classes that implement MockCall and call JUnit > >assertions in the call method. > > > Good point. Since it is MethodMap that really needs the overload > support, method map could determine the concrete method by asking > Constraint for the constrained Class in expectCall/setupCall. But how to > handle MethodMap.setupCall(String methodName, MockCall call)? > > > > >* The MockCall method is very simple so that it is easy to create > >anonymous inner classes that implement from MockCall. I don't want to > >add any additional methods to the MockCall interface to keep this > >simplicity. > > > Yes, what I was thinking of would make doing so a bit harder. Maybe a > more generic AbstractMockCall could aleviate this. > > > > >* Why do you want to add a method to query the state of a MockCall? > >What does the caller of this method do with the queried information? > >And why can the MockCall not do this? (Law of Demeter/Tell Don't Ask). > > > MockCall does not know the method name, let alone the class on which > method is declared. So for MockCall to be able to return the Method [for > use as a key in the MethodMap] it would need to be constructed with the > object or class that is being mocked. Then MethodMap could delegated to > MockCall to get the Method. (Maybe MockCall's hash function could return > method so MockCall does not need to expose Method at all.) > > What explicity were you thinking of "telling" MockCall? To register > itself in the MethodMap as unique Method? > > >I would like to see what the API would be like and how it would be used > >before making such drastc changes. From that we can work towards the > >design of the interna > > > Of course. I'm sure there lots of issues that I have not yet considered. > (I only started looking at the dynamic mocks a couple of days ago.) I'll > knock out a spike, hopefully this weekend, and post it for discussion. I > also need to convert a lot more of our tests to use the dynamic mocks > before I am confident of handling the forces. > > -bk -- Nat Pryce <nat...@b1...> B13media |
From: Barry K. <bk...@in...> - 2002-11-19 16:54:15
|
Nat Pryce wrote: >Here's some ideas for the API. > > interface Overloaded { > void overloaded( int number ); > void overloaded( String text ); > void notOverloaded( int number ); > } > > Mock mock = new Mock( Overloaded.class ); > > > >Set up expectations on overloaded methods: > > mock.expectVoid( "overloaded", new Class[]{int.class}, > P.args(P.eq(1)) ); > mock.expectVoid( "overloaded", new Class[]{String.class}, > P.args(P.eq("1")) ); > > That will certainly work. But I would rather not allow for the mistake of a mismatch between class and object if possible. That is why I wanted Constraint to be responsible for providing the Class as it already knows (once-and-only-once). -bk |
From: Barry K. <bk...@in...> - 2002-11-19 16:38:32
|
> > >I'm confused about this: > >* MockCall *is* part of the public interface. > Adding a method to MockCall will not break existing code. (But it will make creating anonymous inners harder, as you point out below.) >* Constraints do not specify the expected argument types, so I don't see >how querying for a list of constraints will help you overload on >argument types. > Not the constraints, but the Class of the object being constrained. >* MockCall objects do not have to have Constraints -- they can check >argument values in any way they choose. For example, I have tests that >uses anonymous inner classes that implement MockCall and call JUnit >assertions in the call method. > Good point. Since it is MethodMap that really needs the overload support, method map could determine the concrete method by asking Constraint for the constrained Class in expectCall/setupCall. But how to handle MethodMap.setupCall(String methodName, MockCall call)? > >* The MockCall method is very simple so that it is easy to create >anonymous inner classes that implement from MockCall. I don't want to >add any additional methods to the MockCall interface to keep this >simplicity. > Yes, what I was thinking of would make doing so a bit harder. Maybe a more generic AbstractMockCall could aleviate this. > >* Why do you want to add a method to query the state of a MockCall? >What does the caller of this method do with the queried information? >And why can the MockCall not do this? (Law of Demeter/Tell Don't Ask). > MockCall does not know the method name, let alone the class on which method is declared. So for MockCall to be able to return the Method [for use as a key in the MethodMap] it would need to be constructed with the object or class that is being mocked. Then MethodMap could delegated to MockCall to get the Method. (Maybe MockCall's hash function could return method so MockCall does not need to expose Method at all.) What explicity were you thinking of "telling" MockCall? To register itself in the MethodMap as unique Method? >I would like to see what the API would be like and how it would be used >before making such drastc changes. From that we can work towards the >design of the interna > Of course. I'm sure there lots of issues that I have not yet considered. (I only started looking at the dynamic mocks a couple of days ago.) I'll knock out a spike, hopefully this weekend, and post it for discussion. I also need to convert a lot more of our tests to use the dynamic mocks before I am confident of handling the forces. -bk |
From: Barry K. <bk...@in...> - 2002-11-19 16:16:42
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> <blockquote type="cite" cite="mid...@ba..."> <blockquote type="cite"> <pre wrap="">The class I have been using to learn mocksobjects: public interface Position { int getQuantity(PositionBucketType bucketType, PositionTimeType timeType); int getQuantity(LongShort longShort, CreditType creditType, PositionTimeType timeType); .... } Different components of our system know different aspects of a position. The two methods above allow each to access the quantities polymorphically without any ifs or switches. </pre> </blockquote> <pre wrap=""><!----> Java does not dispatch methods polymorphically based on runtime argument types. If your code is calling overloaded methods you don't need ifs and switches.</pre> </blockquote> <br> I was not refering to polymorphism at the overloaded method level, but the ability to not have to do:<br> <br> int quantity<br> if ( bla bla) {<br> getLongCashOvernightQuantity();<br> else if (bla bla) {<br> get ShortCashOvernightQuantity();<br> else if (bla bla)<br> get LongMarginDaytradeQuantity();<br> else if (bla bla)<br> ...<br> <br> (Remember, you asked why overloaded methods were necessary at the interface level. The above is why).<br> <br> <br> </body> </html> |
From: Nat P. <nat...@b1...> - 2002-11-19 16:14:14
|
Here's some ideas for the API. interface Overloaded { void overloaded( int number ); void overloaded( String text ); void notOverloaded( int number ); } Mock mock = new Mock( Overloaded.class ); Set up expectations on overloaded methods: mock.expectVoid( "overloaded", new Class[]{int.class}, P.args(P.eq(1)) ); mock.expectVoid( "overloaded", new Class[]{String.class}, P.args(P.eq("1")) ); Can ignore argument types if there is only one method with a given name: mock.expectVoid( "notOverloaded", P.args(P.eq(2)) ); But specifying argument types will have the same effect: mock.expectVoid( "notOverloaded", new Class[]{int.class}, P.args(P.eq(2)) ); Ignoring argument types for overloaded methods will throw an AssertionFailedError: expectFail( "invalid argument types", new Runnable() { public void run() { mock.expectVoid( "overloaded", P.args(P.eq(1)) ); } } Specifying argument types that are not used by any methods will throw an AssertionFailedError: expectFail( "invalid argument types", new Runnable() { public void run() { mock.expectVoid( "overloaded", new Class[]{bool.class}, P.args(P.eq(true)) ); } } And similarly for the setupXXX methods. Cheers, Nat. -- Nat Pryce <nat...@b1...> B13media |
From: Nat P. <nat...@b1...> - 2002-11-19 15:52:56
|
On Tue, 2002-11-19 at 15:16, Barry Kaplan wrote: > Nat Pryce wrote: > > >I designed the API that way for simplicity rather than completeness. In > >all my use of the dynamic mock library I have not found a need for > >overloaded methods. Overloaded methods they do not seem to be used in > >interfaces. The interfaces which are most likely to use overloaded > >methods (DataOutput for example) don't use them to, I guess, avoid > >silent type coercions and all the tricky bugs they cause. > > > >Supporting overloaded methods would make the API really awkward unless > >the Mock class completely hid the lookup of methods behind a convenient > >set of functions. > > > I believe I can do it without any change to the public interface. > Roughly, what I was thinking of was to add a method to MockCall to > return Class[] corresonding to the method arguments. MockCall would > delegate to its [top-level] Constraints to get the Class's. Thus, given > the name and Class[], MockCall can get the Method and use that as the > key. (MockCall already looks up the Method when invoking a non-proxied > method, but in that case it already has the Object[]'s.) The one > limitation (until jdk 1.5) is that composite Constraint's will simply > give back the first Class of the first contained Constraint. I'm confused about this: * MockCall *is* part of the public interface. * Constraints do not specify the expected argument types, so I don't see how querying for a list of constraints will help you overload on argument types. * MockCall objects do not have to have Constraints -- they can check argument values in any way they choose. For example, I have tests that uses anonymous inner classes that implement MockCall and call JUnit assertions in the call method. * The MockCall method is very simple so that it is easy to create anonymous inner classes that implement from MockCall. I don't want to add any additional methods to the MockCall interface to keep this simplicity. * Why do you want to add a method to query the state of a MockCall? What does the caller of this method do with the queried information? And why can the MockCall not do this? (Law of Demeter/Tell Don't Ask). I would like to see what the API would be like and how it would be used before making such drastc changes. From that we can work towards the design of the internals. > One of the other benefits of this approach is that invocations to > setupCall/expectCall can check that the MockCall represents an actual > method on the interface at the time the call is setup. As it is now, the > test can specify a set of arguments for a non-existant method. This type > of error won't manifest itself until Mock.invoke(). This is partly checked at the moment -- at least there is a check that a method of that name exists. > >Can you give us an example of where you need them? > > > > > The class I have been using to learn mocksobjects: > > public interface Position { > int getQuantity(PositionBucketType bucketType, PositionTimeType > timeType); > int getQuantity(LongShort longShort, CreditType creditType, > PositionTimeType timeType); > .... > } > > Different components of our system know different aspects of a position. > The two methods above allow each to access the quantities > polymorphically without any ifs or switches. Java does not dispatch methods polymorphically based on runtime argument types. If your code is calling overloaded methods you don't need ifs and switches. However, that's by-the-by. The dynamic Mocks should support overloaded methods. I would just like to ensure that support of overloaded methods does not make the common cases (no overloaded methods) harder to use. Cheers, Nat. -- Nat Pryce <nat...@b1...> B13media |
From: Barry K. <bk...@in...> - 2002-11-19 15:11:31
|
Nat Pryce wrote: >I designed the API that way for simplicity rather than completeness. In >all my use of the dynamic mock library I have not found a need for >overloaded methods. Overloaded methods they do not seem to be used in >interfaces. The interfaces which are most likely to use overloaded >methods (DataOutput for example) don't use them to, I guess, avoid >silent type coercions and all the tricky bugs they cause. > >Supporting overloaded methods would make the API really awkward unless >the Mock class completely hid the lookup of methods behind a convenient >set of functions. > I believe I can do it without any change to the public interface. Roughly, what I was thinking of was to add a method to MockCall to return Class[] corresonding to the method arguments. MockCall would delegate to its [top-level] Constraints to get the Class's. Thus, given the name and Class[], MockCall can get the Method and use that as the key. (MockCall already looks up the Method when invoking a non-proxied method, but in that case it already has the Object[]'s.) The one limitation (until jdk 1.5) is that composite Constraint's will simply give back the first Class of the first contained Constraint. One of the other benefits of this approach is that invocations to setupCall/expectCall can check that the MockCall represents an actual method on the interface at the time the call is setup. As it is now, the test can specify a set of arguments for a non-existant method. This type of error won't manifest itself until Mock.invoke(). >Can you give us an example of where you need them? > > The class I have been using to learn mocksobjects: public interface Position { int getQuantity(PositionBucketType bucketType, PositionTimeType timeType); int getQuantity(LongShort longShort, CreditType creditType, PositionTimeType timeType); .... } Different components of our system know different aspects of a position. The two methods above allow each to access the quantities polymorphically without any ifs or switches. What I have done so far is to use explicit CallSequence (actually CallSet, which does not consider order of invocations): public class MockPosition extends Position { private CallSet expectedGetQuantity1 = new CallSet(); public int getQuantity(PositionBucketType bucketType, PositionTimeType timeType) { // use expectedGetQuantity1 } private CallSet expectedGetQuantity2 = new CallSet(); int getQuantity(LongShort longShort, CreditType creditType, PositionTimeType timeType); // use expectedGetQuantity2 } .... } |
From: Barry K. <bk...@in...> - 2002-11-18 22:31:58
|
This is because MethodMap uses the method name as the key (without regard to argument types). In order to support overloaded methods considerable overhauls seem to be necessary. I'm going to do this work, but I'm not sure if it can be completely backward compatible (I'm not even sure if that would be desirable). So, who out there is using dynamic mocks? And how deep is your usage? Has anyone come up with a clean way to support overloaded methods using the current implementation of dynamic mocks? -bk |
From: Barry K. <bk...@in...> - 2002-11-18 15:13:00
|
> > >> I don't see how the ExpectationSet can do this. How to specify the >> mock return value for each key1/key2 combination? Can I use the >> Constraints with ExpectationSet (for mulitple arguments)? > > > We're still thinking about this one, but it's an obvious direction to go. Seems that the dynamic mocksobjects handle this quite nicely. Here's what I did: The class I needed to test was an abstract class, so I could not use Mock or MockObject directly. Instead I mocked just the abstract hook methods required to the test the template methods. In the case of the 'getQuantity' hook method, I did: private CallSet expectedGetQuantity1 = new CallSet(); // Just to provide an easier setup mechansim than having the test use the CallSet directly public void expectGetQuantity(Foo foo, Bar bar, Integer returnValue) { expectedGetQuantity1.expectReturn( new Constraint[]{P.eq(foo), P.eq(bar)}, returnValue); } public int getQuantity(Foo foo, Bar bar) { try return ((Integer) expectedGetQuantity1.call(new Object[]{foo, bar})).intValue(); } catch (Throwable t) { // It kinda sucks that call() declares Throwable. Its really unecessary, since reflection will // throw the exception of the reflected. If the reflected method declares an exception // the mock method can pass it thru (or extract it from the exception the method.invoke() throws). throw new RuntimeException(t); } } public void verify() throws AssertionFailedError { expectedGetQuantity1.verify(); ... } >> >> BTW, are there any other examples floating around (ie, projects that >> make extensive use of mockobjects)? The ones the distribution are ok, >> but not too extensive. > > > not sure, but you could contribute some Well, we have over 3000 unit tests for our system. I looked at mockobjects when we started, but instead decided to use the following very simple mock idiom (aka simplemock): interface: public int getFoo(Bar bar); mock: public boolean getFooCalled; public Integer getFooReturn; public Bar getFooBar; public int getFoo(Bar bar) { getFooCalled = true; getFooBar = bar; return getFooReturn.intValue(); } We have a code generator that creates this simple idiom from interfaces. One of the big problem we ran into with mockobjects was the ability to get back the values passed into mocks (vs. just having the mock assert the values). For example, when testing a class that registers as a listener [with some mock], we often want to get hold of that listener instance (which may be the CUT or an inner of class of the CUT) and invoke methods on the listener so as to test the listening behavior. Implementations of Expectation all maintain the expected values as private and provide no accessors, making this type of usage impossible. On the other hand, testing multiple calls to the mock within a single test using simplemock is painful. You have to explicity code in support. eg, Provide a collection for each argument and return values, or create a custom MockCall abstraction. Back then I never really dug into the mockobjects code. Now, after having done so, I see that the mockobjects implementation is clean and simple, and most of limitations [for us] can easiliy be removed. We used easymock for a while, but had same issues as with mockobjects. As for contributing. I certainly will. Both to the core and dynamic modules, and examples as we incrementally convert. Thanks for the help Steve. -bk (I notice that all your responses post to both user and dev. Should that be the normal practice?) |
From: Steve F. <st...@m3...> - 2002-11-18 00:21:34
|
Barry Kaplan wrote: > Steve Freeman wrote: > I'm still a bit confused. Consider: > > public void class QuantityHolder { > public int getQuantity(Key key1, Key key1); > } > > public int sum(QuantityHolder holder) { > int result = holder.getQuantity("key1", "key2") + > holder.getQuantity("key3", "key4") + ...; > } > > I want to mock QuantityHolder. I want to ensure that sum() invoked the > getQuantity method twice, with the correct keys, but in any order. depends on quite what you want to test, for example: ExpectationSet keys; public int getQuantity(Key key1, Key key2) { keys.addActual(key1); keys.addActual(key2); } would test that all four keys were used, but not the combinations. In practice, would that satisfy you that you'd covered the bases? alternatively, how about a constraint: P.or( P.and(P.eq("key1"), P.eq("key2")), P.and(P.eq("key3"), P.eq("key4"))); which tests that only the right combinations are passed through. If the arguments are always in the same order, you could try: ExpectationSet keys; public int getQuantity(Key key1, Key key2) { keys.addActual(key1 + key2); } Finally, if the arguments can come in any order but the pairs matter, I think you could try: ExpectationSet keys; public int getQuantity(Key key1, Key key2) { Set keySet = new HashSet(); keySet.add(key1); keySet.add(key2); keys.addActual(keySet); } > I don't see how the ExpectationSet can do this. How to specify the mock > return value for each key1/key2 combination? Can I use the Constraints > with ExpectationSet (for mulitple arguments)? We're still thinking about this one, but it's an obvious direction to go. > > -bk > > BTW, are there any other examples floating around (ie, projects that > make extensive use of mockobjects)? The ones the distribution are ok, > but not too extensive. not sure, but you could contribute some... S. |
From: Steve F. <st...@m3...> - 2002-11-17 23:38:16
|
Use expectCall to specify that the method should be called during the test and fail if it doesn't happen. Usually use setupCall to, um, setup return values when a method is called, but we don't care if it is called or what the paramaters are. Use the setup to get the code to work so you can get on to whatever else it is you want to verify. This can sometimes be useful if you want a single setup in a mock that will be used in several different tests. S. Barry Kaplan wrote: > When should expectCall vs setupCall be used? Seems the only differnce is > that setupCall creates a new ExpectationValue (overriding the existing > instance), were expectCall sets the value of the existing instace. > > -bk > > ---- > private ExpectationValue wasCalled; > > public MethodExpectation(String aName) { > name = aName; > initializeWasCalled(); > } > > public void expectCall(MockCall aCall) { > mockCall = aCall; > wasCalled.setExpected(true); > } > > public void setupCall(MockCall aCall) { > mockCall = aCall; > initializeWasCalled(); > } > > private void initializeWasCalled() { > wasCalled = new ExpectationValue(name + " was called"); |
From: Barry K. <bk...@in...> - 2002-11-17 23:11:57
|
Steve Freeman wrote: > Thanks for your proposal in another message. > > You might also consider combining the dynamic mock with a hand-rolled > mock using the ExpectationSet, e.g. > > public void MockFoo extends Mock { > ExpectationSet values = new ExpectationSet("values); > > public void addValue(Value aValue) { // override > values.addActual(aValue); > } > > public void verify() { > super.verify(); > values.verify(); > } > } > I'm still a bit confused. Consider: public void class QuantityHolder { public int getQuantity(Key key1, Key key1); } public int sum(QuantityHolder holder) { int result = holder.getQuantity("key1", "key2") + holder.getQuantity("key3", "key4") + ...; } I want to mock QuantityHolder. I want to ensure that sum() invoked the getQuantity method twice, with the correct keys, but in any order. I don't see how the ExpectationSet can do this. How to specify the mock return value for each key1/key2 combination? Can I use the Constraints with ExpectationSet (for mulitple arguments)? -bk BTW, are there any other examples floating around (ie, projects that make extensive use of mockobjects)? The ones the distribution are ok, but not too extensive. |