mockobjects-java-dev — For people who are working on the implementation of the java version

[MO-java-dev] CVS: mockobjects-java/src/jdk/common/com/mockobjects/sql MockResultSetMetaData.java,1.2,1.3

[Jeff M. <cus...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/sql
In directory usw-pr-cvs1:/tmp/cvs-serv8477/src/jdk/common/com/mockobjects/sql

Modified Files:
	MockResultSetMetaData.java 
Log Message:
Change addColumnName to setupAddColumnName


Index: MockResultSetMetaData.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/jdk/common/com/mockobjects/sql/MockResultSetMetaData.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MockResultSetMetaData.java	16 Apr 2002 17:04:02 -0000	1.2
+++ MockResultSetMetaData.java	22 Apr 2002 16:59:49 -0000	1.3
@@ -8,13 +8,18 @@
 public class MockResultSetMetaData extends MockObject
 implements ResultSetMetaData {
 
-    private Vector myNames = new Vector();
+    private ReturnObjectList myNames = new ReturnObjectList("column names");
+    private int myColumnCount;
+
+    public void setupGetColumnCount(int aColumnCount){
+        myColumnCount = aColumnCount;
+    }
 
     /**
     * @see ResultSetMetaData#getColumnCount()
     */
     public int getColumnCount() throws SQLException {
-        return myNames.size();
+        return myColumnCount;
     }
 
     /**
@@ -81,23 +86,23 @@
         return null;
     }
 
-    public void addColumnNames(String[] allNames) {
+    public void setupAddColumnNames(String[] allNames) {
         if (allNames != null) {
             for (int i = 0; i < allNames.length; i++) {
-                addColumnName(allNames[i]);
+                setupAddColumnName(allNames[i]);
             }
         }
     }
 
-    public void addColumnName(String aName){
-        this.myNames.add(aName);
+    public void setupAddColumnName(String aName){
+        this.myNames.addObjectToReturn(aName);
     }
 
     /**
     * @see ResultSetMetaData#getColumnName(int)
     */
     public String getColumnName(int aColumnIndex) throws SQLException {
-        return (String)myNames.remove(0);
+        return (String)myNames.nextReturnObject();
     }
 
     /**

[MO-java-dev] CVS: mockobjects-java/src/core/com/mockobjects MockObject.java,1.2,1.3

[Jeff M. <cus...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects
In directory usw-pr-cvs1:/tmp/cvs-serv8477/src/core/com/mockobjects

Modified Files:
	MockObject.java 
Log Message:
Change addColumnName to setupAddColumnName


Index: MockObject.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/MockObject.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MockObject.java	22 Apr 2002 16:53:13 -0000	1.2
+++ MockObject.java	22 Apr 2002 16:59:49 -0000	1.3
@@ -30,7 +30,7 @@
      * @deprecated
      */
     protected void notYetImplemented() {
-        notImplemented(this.getClass().getName());
+        notYetImplemented(this.getClass().getName());
     }
 
     /**

[MO-java-dev] CVS: mockobjects-java/src/j2ee/common/com/mockobjects/jms MockMessagePublisher.java,1.1,1.2 MockTopic.java,1.1,1.2 MockTopicConnection.java,1.1,1.2 MockTopicPublisher.java,1.1,1.2 MockTopicSession.java,1.2,1.3 MockTopicSubscriber.java,1.1,1.2

[Jeff M. <cus...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/jms
In directory usw-pr-cvs1:/tmp/cvs-serv5570/src/j2ee/common/com/mockobjects/jms

Modified Files:
	MockMessagePublisher.java MockTopic.java 
	MockTopicConnection.java MockTopicPublisher.java 
	MockTopicSession.java MockTopicSubscriber.java 
Log Message:
Stop using deprecated notYetImplemeted


Index: MockMessagePublisher.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/jms/MockMessagePublisher.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockMessagePublisher.java	23 Feb 2002 18:50:35 -0000	1.1
+++ MockMessagePublisher.java	22 Apr 2002 16:53:13 -0000	1.2
@@ -5,54 +5,54 @@
 
 public class MockMessagePublisher extends MockObject implements MessageProducer{
     public void close() throws JMSException{
-        notYetImplemented();
+        notImplemented();
     }
 
     public int getDeliveryMode() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return -1;
     }
 
     public boolean getDisableMessageID() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return false;
     }
 
     public boolean getDisableMessageTimestamp() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return false;
     }
 
     public int getPriority() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return -1;
     }
 
     public long getTimeToLive() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return -1;
     }
 
     public void setDeliveryMode(int deliveryMode) throws JMSException{
-        notYetImplemented();
+        notImplemented();
     }
 
     public void setDisableMessageID(boolean disableMessageId)
     throws JMSException{
-        notYetImplemented();
+        notImplemented();
     }
 
     public void setDisableMessageTimestamp(boolean disableMessageTimeStamp)
     throws JMSException{
-        notYetImplemented();
+        notImplemented();
     }
 
     public void setPriority(int priority) throws JMSException{
-        notYetImplemented();
+        notImplemented();
     }
 
     public void setTimeToLive(long timeToLive) throws JMSException{
-        notYetImplemented();
+        notImplemented();
     }
 
 }

Index: MockTopic.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/jms/MockTopic.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockTopic.java	23 Feb 2002 18:50:35 -0000	1.1
+++ MockTopic.java	22 Apr 2002 16:53:13 -0000	1.2
@@ -6,7 +6,7 @@
 public class MockTopic extends MockObject implements Topic{
 
     public String getTopicName() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 

Index: MockTopicConnection.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/jms/MockTopicConnection.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockTopicConnection.java	23 Feb 2002 18:50:35 -0000	1.1
+++ MockTopicConnection.java	22 Apr 2002 16:53:13 -0000	1.2
@@ -15,7 +15,7 @@
     String messageSelector, ServerSessionPool sessionPool, int maxMessages)
     throws JMSException{
 
-        notYetImplemented();
+        notImplemented();
         return null;
     }
     
@@ -23,7 +23,7 @@
     String subscriptionName, String messageSelector,
     ServerSessionPool sessionPool, int maxMessages) throws JMSException{
 
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 

Index: MockTopicPublisher.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/jms/MockTopicPublisher.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockTopicPublisher.java	23 Feb 2002 18:50:35 -0000	1.1
+++ MockTopicPublisher.java	22 Apr 2002 16:53:13 -0000	1.2
@@ -13,7 +13,7 @@
     }
 
     public Topic getTopic() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 

Index: MockTopicSession.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/jms/MockTopicSession.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- MockTopicSession.java	15 Mar 2002 17:37:06 -0000	1.2
+++ MockTopicSession.java	22 Apr 2002 16:53:13 -0000	1.3
@@ -55,7 +55,7 @@
     }
 
     public TemporaryTopic createTemporaryTopic() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -66,7 +66,7 @@
     }
 
     public void unsubscribe(String topicName) throws JMSException{
-        notYetImplemented();
+        notImplemented();
     }
 
 }

Index: MockTopicSubscriber.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/jms/MockTopicSubscriber.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockTopicSubscriber.java	23 Feb 2002 18:50:35 -0000	1.1
+++ MockTopicSubscriber.java	22 Apr 2002 16:53:13 -0000	1.2
@@ -7,12 +7,12 @@
 implements TopicSubscriber{
 
     public boolean getNoLocal() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return false;
     }
 
     public Topic getTopic() throws JMSException{
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet MockHttpServletRequest.java,1.3,1.4

[Jeff M. <cus...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet
In directory usw-pr-cvs1:/tmp/cvs-serv5570/src/j2ee/1.3/com/mockobjects/servlet

Modified Files:
	MockHttpServletRequest.java 
Log Message:
Stop using deprecated notYetImplemeted


Index: MockHttpServletRequest.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet/MockHttpServletRequest.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- MockHttpServletRequest.java	5 Apr 2002 10:49:49 -0000	1.3
+++ MockHttpServletRequest.java	22 Apr 2002 16:53:13 -0000	1.4
@@ -39,17 +39,17 @@
     }
 
     public java.util.Enumeration getAttributeNames() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public String getAuthType() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public String getCharacterEncoding() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -58,7 +58,7 @@
     }
 
     public String getContentType() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -67,12 +67,12 @@
     }
 
     public java.lang.String getContextPath() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public javax.servlet.http.Cookie[] getCookies() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -85,12 +85,12 @@
     }
 
     public java.util.Enumeration getHeaderNames() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public java.util.Enumeration getHeaders(java.lang.String arg1) {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -108,12 +108,12 @@
     }
 
     public java.util.Locale getLocale() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public java.util.Enumeration getLocales() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -146,27 +146,27 @@
     }
 
     public String getPathTranslated() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public String getProtocol() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public String getQueryString() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public java.io.BufferedReader getReader() throws java.io.IOException {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public String getRealPath(String arg1) {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -179,23 +179,23 @@
     }
 
     public String getRemoteHost() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public String getRemoteUser() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public javax.servlet.RequestDispatcher getRequestDispatcher(
         java.lang.String arg1) {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public String getRequestedSessionId() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -208,12 +208,12 @@
     }
 
     public String getScheme() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
     public String getServerName() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -222,7 +222,7 @@
     }
 
     public String getServletPath() {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 
@@ -235,7 +235,7 @@
     }
 
     public HttpSession getSession(boolean arg1) {
-        notYetImplemented();
+        notImplemented();
         return null;
     }
 

[MO-java-dev] CVS: mockobjects-java/src/core/com/mockobjects MockObject.java,1.1,1.2

[Jeff M. <cus...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects
In directory usw-pr-cvs1:/tmp/cvs-serv5570/src/core/com/mockobjects

Modified Files:
	MockObject.java 
Log Message:
Stop using deprecated notYetImplemeted


Index: MockObject.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/MockObject.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockObject.java	29 Jul 2001 19:50:24 -0000	1.1
+++ MockObject.java	22 Apr 2002 16:53:13 -0000	1.2
@@ -30,7 +30,7 @@
      * @deprecated
      */
     protected void notYetImplemented() {
-        notYetImplemented(this.getClass().getName());
+        notImplemented(this.getClass().getName());
     }
 
     /**

[MO-java-dev] CVS: mockobjects-java/src/j2ee/common/com/mockobjects/naming MockContext.java,1.1,1.2

[Jeff M. <cus...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/naming
In directory usw-pr-cvs1:/tmp/cvs-serv32029/src/j2ee/common/com/mockobjects/naming

Modified Files:
	MockContext.java 
Log Message:
Changed to allow multiple lookups to be defined


Index: MockContext.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/naming/MockContext.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockContext.java	22 Feb 2002 16:25:05 -0000	1.1
+++ MockContext.java	22 Apr 2002 16:43:32 -0000	1.2
@@ -1,10 +1,12 @@
 package com.mockobjects.naming;
 
-import javax.naming.*;
 import com.mockobjects.*;
+import java.util.Vector;
+import javax.naming.*;
 
 public class MockContext extends MockObject implements Context{
-    private Object myObjectToReturn;
+    private final ReturnObjectList myLookupObjects =
+        new ReturnObjectList("lookups");
     private ExpectationValue myBindName = new ExpectationValue(
         MockContext.class.getName() + "myBindName");
     private ExpectationValue myBindObject = new ExpectationValue(
@@ -14,8 +16,8 @@
     private ExpectationValue myLookupName = new ExpectationValue(
         MockContext.class.getName() + "myLookupName");
 
-    public void setupLookup(Object aObjectToReturn){
-        this.myObjectToReturn = aObjectToReturn;
+    public void setupAddLookup(Object aObjectToReturn){
+        this.myLookupObjects.addObjectToReturn(aObjectToReturn);
     }
 
     public void setExpectedLookupName(String aLookupName){
@@ -24,12 +26,12 @@
 
     public Object lookup(Name name) throws NamingException{
         this.myLookupName.setActual(name);
-        return myObjectToReturn;
+        return myLookupObjects.nextReturnObject();
     }
 
     public Object lookup(String name) throws NamingException{
         this.myLookupName.setActual(name);
-        return myObjectToReturn;
+        return myLookupObjects.nextReturnObject();
     }
 
     public void bind(Name aBindName, Object aBindObject) throws NamingException{

[MO-java-dev] CVS: mockobjects-java/src/core/com/mockobjects ReturnObjectList.java,NONE,1.1

[Jeff M. <cus...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects
In directory usw-pr-cvs1:/tmp/cvs-serv31235/src/core/com/mockobjects

Added Files:
	ReturnObjectList.java 
Log Message:
Added new object to handle lists of returned objects


--- NEW FILE: ReturnObjectList.java ---
package com.mockobjects;

import com.mockobjects.util.AssertMo;

import java.util.Vector;

public class ReturnObjectList implements Verifiable {

    private final Vector myObjects = new Vector();
    private final String myName;

    public ReturnObjectList(String aName) {
        this.myName = aName;
    }

    public void addObjectToReturn(Object anObjectToReturn){
        myObjects.add(anObjectToReturn);
    }

    public Object nextReturnObject(){
        if(myObjects.size()>0){
            return myObjects.remove(0);
        }else{
            AssertMo.fail(myName + " has run out of objects.");
            return null;
        }
    }

    public void verify() {
        AssertMo.assertEquals(myName + " has un-used objects.", 0, myObjects.size());
    }
}

Re: [MO-java-dev] javax.mail.Session and Facading

[Jeff M. <je...@mk...>]

On Fri, 2002-04-19 at 00:55, Steve Freeman wrote:
> From: "Jeff Martin" <je...@mk...>
> > Anyone got any opinions about creating facades around un-mockable
> > classes such as javax.mail.Session which is final.
> >
> > So we end up with:-
> > Interface redefining the class
> > Facade around the sun implementation
> > Mock implementation of the interface
> 
> pretty much, which is not a bad idea anyway, unless you can figure out
> how to feed enough related objects to the Session to make it behave as
> you need.
> 
> S.
> 
The next question is now I've got a basic alternative implementation to
the mail api. Where do I put it? at the mo everything is in
com.mockobjects.mail but that mean I end up import com.mockobjects sub
packages into my real code (eek!)

Might just move them to alt.javax.mail?

> 
> 
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 

Re: [MO-java-dev] MockConnection

[Jeff M. <je...@mk...>]

I spent sometime yesterday, working through the mail facade stuff,
gradually implementing the bits I needed (tiny tiny steps), and the
processes worked quite well. I don't know whether it would have worked
so well if I'd of had to write a test as well. There's great temptation
then as well to write tests for methods which you personally don't need,
and end up with mocks that aren't built from usage but from planning.

Maybe that stuff just need a bit more refactoring.


On Thu, 2002-04-18 at 23:40, Steve Freeman wrote:
> From: "Jeff Martin" <je...@mk...>
> > On Wed, 2002-04-17 at 22:43, Steve Freeman wrote:
> > > > Actually the general consensus is that mocks don't need tests. The
> > > idea
> > > > is to keep them really simply so there's nothing in them worth
> > > testing.
> > > > That's the good thing about the expectation stuff. That's got
> tests
> > > and
> > > > that's the bit that doe's the work.
> > >
> > > Actually, I'm beginning to turn on this one. For long-term mocks,
> such
> > > as in the library, it's sometimes hard to tell what they do, and it
> > > might not be a bad idea to write the unit tests for documentation --
> > > rather than more javadoc.
> 
> > Hmm, not sure, shouldn't the code be as self explanatory as possible.
> > Most of the the mocks should be pretty simple.
> 
> I know this argument, since I made it a lot, but now I find that I'm
> coming back to some of the more complex mocks (such as the sql library)
> and can't remember what they do. Unfortunately, some of the standard
> interfaces are so bloated that the associated mocks are likely to be
> complex.
> 
> I wouldn't make it mandatory, but would like to encourage it.
> 
> Steve
> 
> 
> 
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 

Re: [MO-java-dev] InterfaceImplementor

[Jeff M. <je...@mk...>]

On Thu, 2002-04-18 at 19:40, Scott Lamb wrote:
> On Thu, Apr 18, 2002 at 12:23:57PM +0100, Jeff Martin wrote:
> > Here you go. Just drop it into ~/.vim/plugin, start up vim, type :call
> > MockIt("this.is.the.Interface")
> > 
> > Easy as that.
> > 
> > Still need to sort out a proper name mapping so you can do
> > 
> > :mockit this.is.the.Interface
> > 
> > and it doesn't put in variable names for the method arguments, but I'll
> > get there.
> 
> I still say this isn't as good. Even though you don't have to manually type
> out the interface the first time,

It was a half joke really, people are trying to persuade me that I
should use an ide, coz it save you time doing a couple of things. I like
vim, it saves me hassle nearly ever single keystroke

> 
> - if the interface changes (as in the SQL example), you need to manually
>   sort it out. With the stubs, you don't.

Doesn't this then mean that we revert to the stub implementation, which
will thrown an exception only when it's called. Not at compilation. Well
only know about the problem when someone tries to use the mock not when
the interface was changed. I'd prefer not to have the class compile than
to silently change it's behavior. We end up loosing the advantage of
having a compiled language. This is a similar point to tim's.

> - it's more work to catch errors. My stub generator will immediately
>   complain if there are conflicting methods with the same signature. (Or
>   should. It needs more testing.)
> - the source code is cluttered up with lots of methods that aren't
>   implemented, obscuring what actually does work.

I'm in two minds about this point, cluttered code bad, on the other
hand. You can just look at stack-trace telling you which line is not
implemented, go to the line and add the code. Works quite well I find.

> 
> --
> Scott Lamb
> 
Keep going you might yet persuade me ;o)

Re: [MO-java-dev] javax.mail.Session and Facading

[Steve F. <st...@m3...>]

From: "Jeff Martin" <je...@mk...>
> Anyone got any opinions about creating facades around un-mockable
> classes such as javax.mail.Session which is final.
>
> So we end up with:-
> Interface redefining the class
> Facade around the sun implementation
> Mock implementation of the interface

pretty much, which is not a bad idea anyway, unless you can figure out
how to feed enough related objects to the Session to make it behave as
you need.

S.

Re: [MO-java-dev] MockConnection

[Steve F. <st...@m3...>]

From: "Jeff Martin" <je...@mk...>
> On Wed, 2002-04-17 at 22:43, Steve Freeman wrote:
> > > Actually the general consensus is that mocks don't need tests. The
> > idea
> > > is to keep them really simply so there's nothing in them worth
> > testing.
> > > That's the good thing about the expectation stuff. That's got
tests
> > and
> > > that's the bit that doe's the work.
> >
> > Actually, I'm beginning to turn on this one. For long-term mocks,
such
> > as in the library, it's sometimes hard to tell what they do, and it
> > might not be a bad idea to write the unit tests for documentation --
> > rather than more javadoc.

> Hmm, not sure, shouldn't the code be as self explanatory as possible.
> Most of the the mocks should be pretty simple.

I know this argument, since I made it a lot, but now I find that I'm
coming back to some of the more complex mocks (such as the sql library)
and can't remember what they do. Unfortunately, some of the standard
interfaces are so bloated that the associated mocks are likely to be
complex.

I wouldn't make it mandatory, but would like to encourage it.

Steve

RE: [MO-java-dev] InterfaceImplementor

[Tim M. <tim...@po...>]

Guys -

Am quite taken by the fact that people are using this stuff now - so the
discussions are interesting the contributions well received.

With regards to dynamic proxies - the idea is good, however I can't escape
the fact that having mock objects complain when you change things (e.g. they
break) has actually saved my bacon a number of times when refactoring or
making changes. It really drives home what will be affected. This could of
course be a different way of working so I am personally still considering
how it would change the way I code. At the moment I like the clean breaks
(eg. obvious compile errors).

Tim

-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Steve Freeman
Sent: 17 April 2002 22:22
To: MockObjects
Subject: Re: [MO-java-dev] InterfaceImplementor


For those of us (unlike Jeff) using an IDE, aligning class with
interfaces is pretty easy.

What I find more interesting is the idea of using dynamic proxies to
catch the unimplemented methods (like Smalltalk doesNotUnderstand),
rather than the EasyMock approach of using a dynamic proxy to record and
playback the behaviour. You could then use local overrides to implement
the behaviour for a given test. Now Jeff has split the jdk's it might be
worth investigating this for versions 1.3+

Steve

----- Original Message -----
From: "Jeff Martin" <je...@mk...>
To: "MockObjects" <moc...@li...>
Sent: Wednesday, April 17, 2002 1:53 PM
Subject: Re: [MO-java-dev] InterfaceImplementor


> My problem is with the autogeneration, but with what is being
generated.
> I'm not happy with having the stub classes which are gradually
> superseded, I think it could leave us with lots of classes which
> eventually serve no useful purpose.
>
> As a starting point for new mocks I don't have a problem with
generating
> the code, but creating stubs for everything is not something I'm happy
> with.
>
> But of course that's just my opinion, others may feel differently ;o)
>
> On Wed, 2002-04-17 at 13:25, Scott Lamb wrote:
> > On Wed, Apr 17, 2002 at 11:46:28AM +0100, Jeff Martin wrote:
> > > Thanks for this, but I'm not sure it's really the approach we want
to be
> > > taking. I'd prefer to keep things a bit cleaner even if that means
> > > having lots of methods with just notImplemented(); in them.
> >
> > I have to disagree - I don't think that's the clean approach. I
don't like the
> > idea of humans creating anything repetitive, anything that a
computer could
> > create. There's more possibility for error that way. Or even
copying/pasting
> > repetitive, automatically generated code. That code just serves to
obscure
> > where the real work is being done.
> >
> > > You might be interested in
> > > http://www.xpdeveloper.com/cgi-bin/wiki.cgi?MockMaker which takes
your
> > > approach a bit further.
> > >
> > > There is also some work being done on use java.lang.reflect.Proxy
to
> > > provide a default mock implementation. But I'm not aware of the
details
> > > of this yet.
> >
> > Those are both interesting. I'll look more at them.




_______________________________________________
Mockobjects-java-dev mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.349 / Virus Database: 195 - Release Date: 15/04/2002

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.349 / Virus Database: 195 - Release Date: 15/04/2002

Re: [MO-java-dev] InterfaceImplementor

[Scott L. <sl...@sl...>]

On Thu, Apr 18, 2002 at 12:23:57PM +0100, Jeff Martin wrote:
> Here you go. Just drop it into ~/.vim/plugin, start up vim, type :call
> MockIt("this.is.the.Interface")
> 
> Easy as that.
> 
> Still need to sort out a proper name mapping so you can do
> 
> :mockit this.is.the.Interface
> 
> and it doesn't put in variable names for the method arguments, but I'll
> get there.

I still say this isn't as good. Even though you don't have to manually type
out the interface the first time,

- if the interface changes (as in the SQL example), you need to manually
  sort it out. With the stubs, you don't.
- it's more work to catch errors. My stub generator will immediately
  complain if there are conflicting methods with the same signature. (Or
  should. It needs more testing.)
- the source code is cluttered up with lots of methods that aren't
  implemented, obscuring what actually does work.

--
Scott Lamb

Re: [MO-java-dev] MockConnection

[Jeff M. <je...@mk...>]

On Wed, 2002-04-17 at 22:43, Steve Freeman wrote:
> > Actually the general consensus is that mocks don't need tests. The
> idea
> > is to keep them really simply so there's nothing in them worth
> testing.
> > That's the good thing about the expectation stuff. That's got tests
> and
> > that's the bit that doe's the work.
> 
> Actually, I'm beginning to turn on this one. For long-term mocks, such
> as in the library, it's sometimes hard to tell what they do, and it
> might not be a bad idea to write the unit tests for documentation --
> rather than more javadoc.
> 
> S.
> 

Hmm, not sure, shouldn't the code be as self explanatory as possible.
Most of the the mocks should be pretty simple.

I don't think there's any need for a blanket requirement on mocks to
have tests, but if people provide them that's fine. I find that if you
write the mocks as you write the code and the test you don't need a
test.

Re: [MO-java-dev] My stab at adding java.sql.CallableStatement support

[Jeff M. <je...@mk...>]

Happy to see anything that might be of use.

On Wed, 2002-04-17 at 22:52, Trenton Lipscomb wrote:
> I stumbled on MockObjects about a month ago, but it wasn't until recently that I had the R&D time to play around with it. I really like all the side effects that are gained by using MockObjects. Sure, it's a good way to test, but it really focus your testing on a particular section of code and makes sure that both sides of a given API know that the other expects. Very cool stuff.
> 
> I had to add java.sql.CallableStatement (CS) support to the system, though. I only have it validating that the correct SP names are called. I don't have support for parameter matching (yet). But, it works insomuch as you can make sure a given set of SPs are called in a given order. It also supports creating more than one CS on the same MockConnection.
> 
> Would anyone be interested in taking a look at that? Right now, my additions works well and are commented. I don't follow the MockObjects coding spec, partially because I didn't see it until today.
> 
> *trenton
> 
> ________________________________________
> Trenton Lipscomb                CNET.com
> Sr Software Engineer      The source for
> tre...@cn...          computers and
> 415-344-2275                 technology.
> 
> Does this email regard a patch to XDL? Read this!
> http://nw-stage.cnet.com:8001/cgi-bin/fom.cgi?file=1418
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 

[MO-java-dev] javax.mail.Session and Facading

[Jeff M. <je...@mk...>]

Anyone got any opinions about creating facades around un-mockable
classes such as javax.mail.Session which is final.

So we end up with:-
	Interface redefining the class
	Facade around the sun implementation
	Mock implementation of the interface
-- 

Re: [MO-java-dev] InterfaceImplementor

[Jeff M. <je...@mk...>]

Here you go. Just drop it into ~/.vim/plugin, start up vim, type :call
MockIt("this.is.the.Interface")

Easy as that.

Still need to sort out a proper name mapping so you can do

:mockit this.is.the.Interface

and it doesn't put in variable names for the method arguments, but I'll
get there.


On Wed, 2002-04-17 at 22:21, Steve Freeman wrote:
> For those of us (unlike Jeff) using an IDE, aligning class with
> interfaces is pretty easy.
> 
> What I find more interesting is the idea of using dynamic proxies to
> catch the unimplemented methods (like Smalltalk doesNotUnderstand),
> rather than the EasyMock approach of using a dynamic proxy to record and
> playback the behaviour. You could then use local overrides to implement
> the behaviour for a given test. Now Jeff has split the jdk's it might be
> worth investigating this for versions 1.3+
> 
> Steve
> 
> ----- Original Message -----
> From: "Jeff Martin" <je...@mk...>
> To: "MockObjects" <moc...@li...>
> Sent: Wednesday, April 17, 2002 1:53 PM
> Subject: Re: [MO-java-dev] InterfaceImplementor
> 
> 
> > My problem is with the autogeneration, but with what is being
> generated.
> > I'm not happy with having the stub classes which are gradually
> > superseded, I think it could leave us with lots of classes which
> > eventually serve no useful purpose.
> >
> > As a starting point for new mocks I don't have a problem with
> generating
> > the code, but creating stubs for everything is not something I'm happy
> > with.
> >
> > But of course that's just my opinion, others may feel differently ;o)
> >
> > On Wed, 2002-04-17 at 13:25, Scott Lamb wrote:
> > > On Wed, Apr 17, 2002 at 11:46:28AM +0100, Jeff Martin wrote:
> > > > Thanks for this, but I'm not sure it's really the approach we want
> to be
> > > > taking. I'd prefer to keep things a bit cleaner even if that means
> > > > having lots of methods with just notImplemented(); in them.
> > >
> > > I have to disagree - I don't think that's the clean approach. I
> don't like the
> > > idea of humans creating anything repetitive, anything that a
> computer could
> > > create. There's more possibility for error that way. Or even
> copying/pasting
> > > repetitive, automatically generated code. That code just serves to
> obscure
> > > where the real work is being done.
> > >
> > > > You might be interested in
> > > > http://www.xpdeveloper.com/cgi-bin/wiki.cgi?MockMaker which takes
> your
> > > > approach a bit further.
> > > >
> > > > There is also some work being done on use java.lang.reflect.Proxy
> to
> > > > provide a default mock implementation. But I'm not aware of the
> details
> > > > of this yet.
> > >
> > > Those are both interesting. I'll look more at them.
> 
> 
> 
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 

Re: [MO-java-dev] InterfaceImplementor

[Jeff M. <je...@mk...>]

I find !!javap path.to.Interface works fairly, and I bet if I wasn't so
lazy I could write a vim macro to do the rest. Someones implemented
tetris in vim so I should be able do do that. Try that in IDEA ;-P

!!javap path.to.Interface
:1,$s/abstract //
:1,$s/;/{^M^I^InotImplemented();^M}

That would probably do it.

On Wed, 2002-04-17 at 22:21, Steve Freeman wrote:
> For those of us (unlike Jeff) using an IDE, aligning class with
> interfaces is pretty easy.
> 
> What I find more interesting is the idea of using dynamic proxies to
> catch the unimplemented methods (like Smalltalk doesNotUnderstand),
> rather than the EasyMock approach of using a dynamic proxy to record and
> playback the behaviour. You could then use local overrides to implement
> the behaviour for a given test. Now Jeff has split the jdk's it might be
> worth investigating this for versions 1.3+
> 
> Steve
> 
> ----- Original Message -----
> From: "Jeff Martin" <je...@mk...>
> To: "MockObjects" <moc...@li...>
> Sent: Wednesday, April 17, 2002 1:53 PM
> Subject: Re: [MO-java-dev] InterfaceImplementor
> 
> 
> > My problem is with the autogeneration, but with what is being
> generated.
> > I'm not happy with having the stub classes which are gradually
> > superseded, I think it could leave us with lots of classes which
> > eventually serve no useful purpose.
> >
> > As a starting point for new mocks I don't have a problem with
> generating
> > the code, but creating stubs for everything is not something I'm happy
> > with.
> >
> > But of course that's just my opinion, others may feel differently ;o)
> >
> > On Wed, 2002-04-17 at 13:25, Scott Lamb wrote:
> > > On Wed, Apr 17, 2002 at 11:46:28AM +0100, Jeff Martin wrote:
> > > > Thanks for this, but I'm not sure it's really the approach we want
> to be
> > > > taking. I'd prefer to keep things a bit cleaner even if that means
> > > > having lots of methods with just notImplemented(); in them.
> > >
> > > I have to disagree - I don't think that's the clean approach. I
> don't like the
> > > idea of humans creating anything repetitive, anything that a
> computer could
> > > create. There's more possibility for error that way. Or even
> copying/pasting
> > > repetitive, automatically generated code. That code just serves to
> obscure
> > > where the real work is being done.
> > >
> > > > You might be interested in
> > > > http://www.xpdeveloper.com/cgi-bin/wiki.cgi?MockMaker which takes
> your
> > > > approach a bit further.
> > > >
> > > > There is also some work being done on use java.lang.reflect.Proxy
> to
> > > > provide a default mock implementation. But I'm not aware of the
> details
> > > > of this yet.
> > >
> > > Those are both interesting. I'll look more at them.
> 
> 
> 
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 

RE: [MO-java-dev] MockResultSetMetaData

[Oskar H. <osk...@de...>]

I hope I understood this 1-based index correctly but according to the
Javadoc for ResultSetMetaData.getColumnName(...) the first column is 1, the
second is 2, etc.

Oskar


-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Steve Freeman
Sent: 17. apr=EDl 2002 21:15
To: moc...@li...
Subject: Re: [MO-java-dev] MockResultSetMetaData


a couple of points.

Can we change addColumnName() to setupAddColumnName() ? We adopted this
convention to distinguish mock-specific methods from real API and
'setup' is reasonably unlikely to clash.

Why does getColumnName() call remove() rather than get() ? Also,
shouldn't this converted from a 1-based index to a 0-based index?

Ta
Steve




=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Mockobjects-java-dev mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

Re: [MO-java-dev] MockConnection

[Steve F. <st...@m3...>]

> Actually the general consensus is that mocks don't need tests. The
idea
> is to keep them really simply so there's nothing in them worth
testing.
> That's the good thing about the expectation stuff. That's got tests
and
> that's the bit that doe's the work.

Actually, I'm beginning to turn on this one. For long-term mocks, such
as in the library, it's sometimes hard to tell what they do, and it
might not be a bad idea to write the unit tests for documentation --
rather than more javadoc.

S.

[MO-java-dev] My stab at adding java.sql.CallableStatement support

[Trenton L. <Tre...@cn...>]

I stumbled on MockObjects about a month ago, but it wasn't until recently that I had the R&D time to play around with it. I really like all the side effects that are gained by using MockObjects. Sure, it's a good way to test, but it really focus your testing on a particular section of code and makes sure that both sides of a given API know that the other expects. Very cool stuff.

I had to add java.sql.CallableStatement (CS) support to the system, though. I only have it validating that the correct SP names are called. I don't have support for parameter matching (yet). But, it works insomuch as you can make sure a given set of SPs are called in a given order. It also supports creating more than one CS on the same MockConnection.

Would anyone be interested in taking a look at that? Right now, my additions works well and are commented. I don't follow the MockObjects coding spec, partially because I didn't see it until today.

*trenton

________________________________________
Trenton Lipscomb                CNET.com
Sr Software Engineer      The source for
tre...@cn...          computers and
415-344-2275                 technology.

Does this email regard a patch to XDL? Read this!
http://nw-stage.cnet.com:8001/cgi-bin/fom.cgi?file=1418

Re: [MO-java-dev] InterfaceImplementor

[Steve F. <st...@m3...>]

For those of us (unlike Jeff) using an IDE, aligning class with
interfaces is pretty easy.

What I find more interesting is the idea of using dynamic proxies to
catch the unimplemented methods (like Smalltalk doesNotUnderstand),
rather than the EasyMock approach of using a dynamic proxy to record and
playback the behaviour. You could then use local overrides to implement
the behaviour for a given test. Now Jeff has split the jdk's it might be
worth investigating this for versions 1.3+

Steve

----- Original Message -----
From: "Jeff Martin" <je...@mk...>
To: "MockObjects" <moc...@li...>
Sent: Wednesday, April 17, 2002 1:53 PM
Subject: Re: [MO-java-dev] InterfaceImplementor


> My problem is with the autogeneration, but with what is being
generated.
> I'm not happy with having the stub classes which are gradually
> superseded, I think it could leave us with lots of classes which
> eventually serve no useful purpose.
>
> As a starting point for new mocks I don't have a problem with
generating
> the code, but creating stubs for everything is not something I'm happy
> with.
>
> But of course that's just my opinion, others may feel differently ;o)
>
> On Wed, 2002-04-17 at 13:25, Scott Lamb wrote:
> > On Wed, Apr 17, 2002 at 11:46:28AM +0100, Jeff Martin wrote:
> > > Thanks for this, but I'm not sure it's really the approach we want
to be
> > > taking. I'd prefer to keep things a bit cleaner even if that means
> > > having lots of methods with just notImplemented(); in them.
> >
> > I have to disagree - I don't think that's the clean approach. I
don't like the
> > idea of humans creating anything repetitive, anything that a
computer could
> > create. There's more possibility for error that way. Or even
copying/pasting
> > repetitive, automatically generated code. That code just serves to
obscure
> > where the real work is being done.
> >
> > > You might be interested in
> > > http://www.xpdeveloper.com/cgi-bin/wiki.cgi?MockMaker which takes
your
> > > approach a bit further.
> > >
> > > There is also some work being done on use java.lang.reflect.Proxy
to
> > > provide a default mock implementation. But I'm not aware of the
details
> > > of this yet.
> >
> > Those are both interesting. I'll look more at them.

Re: [MO-java-dev] MockResultSetMetaData

[Steve F. <st...@m3...>]

a couple of points.

Can we change addColumnName() to setupAddColumnName() ? We adopted this
convention to distinguish mock-specific methods from real API and
'setup' is reasonably unlikely to clash.

Why does getColumnName() call remove() rather than get() ? Also,
shouldn't this converted from a 1-based index to a 0-based index?

Ta
Steve

Re: [MO-java-dev] InterfaceImplementor

[Jeff M. <je...@mk...>]

My problem is with the autogeneration, but with what is being generated.
I'm not happy with having the stub classes which are gradually
superseded, I think it could leave us with lots of classes which
eventually serve no useful purpose.

As a starting point for new mocks I don't have a problem with generating
the code, but creating stubs for everything is not something I'm happy
with.

But of course that's just my opinion, others may feel differently ;o)

On Wed, 2002-04-17 at 13:25, Scott Lamb wrote:
> On Wed, Apr 17, 2002 at 11:46:28AM +0100, Jeff Martin wrote:
> > Thanks for this, but I'm not sure it's really the approach we want to be
> > taking. I'd prefer to keep things a bit cleaner even if that means
> > having lots of methods with just notImplemented(); in them. 
> 
> I have to disagree - I don't think that's the clean approach. I don't like the
> idea of humans creating anything repetitive, anything that a computer could
> create. There's more possibility for error that way. Or even copying/pasting
> repetitive, automatically generated code. That code just serves to obscure
> where the real work is being done.
> 
> > You might be interested in
> > http://www.xpdeveloper.com/cgi-bin/wiki.cgi?MockMaker which takes your
> > approach a bit further. 
> > 
> > There is also some work being done on use java.lang.reflect.Proxy to
> > provide a default mock implementation. But I'm not aware of the details
> > of this yet.
> 
> Those are both interesting. I'll look more at them. 
> 
> Thanks.
> 
> --
> Scott Lamb
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
--