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

[MO-java-dev] CVS: no-stone-unturned/rubysrc addrservlet.rb,1.1,1.2 test_addrservlet.rb,1.1,1.2

[Nat P. <np...@us...>]

Update of /cvsroot/mockobjects/no-stone-unturned/rubysrc
In directory usw-pr-cvs1:/tmp/cvs-serv3484

Modified Files:
	addrservlet.rb test_addrservlet.rb 
Log Message:
Minor code cleanup


Index: addrservlet.rb
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/rubysrc/addrservlet.rb,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- addrservlet.rb	27 Aug 2002 19:21:35 -0000	1.1
+++ addrservlet.rb	27 Aug 2002 19:35:34 -0000	1.2
@@ -5,6 +5,6 @@
 class AddressBookServlet < WEBrick::HTTPServlet::AbstractServlet
     def do_GET( request, response )
         response['content-type'] = 'text/plain'
-        response.body = 'no addresses found'
+        response.body = 'no address found'
     end
 end

Index: test_addrservlet.rb
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/rubysrc/test_addrservlet.rb,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- test_addrservlet.rb	27 Aug 2002 19:21:35 -0000	1.1
+++ test_addrservlet.rb	27 Aug 2002 19:35:34 -0000	1.2
@@ -17,13 +17,13 @@
     end
     
     def []=( header, value )
-        assert_equal( 'content-type', header )
+        assert_equal( "content-type", header )
         assert_match( /^text\/.*/, value )
         @content_type_set = true
     end
     
     def body=( value )
-        assert_match( /no addresses found/, value )
+        assert_match( /no address found/, value )
         @body_set = true
     end
     
@@ -35,7 +35,7 @@
 
 
 class AddressBookServletTest < Test::Unit::TestCase
-    def test_no_addresses_found
+    def test_no_address_found
         request = MockRequest.new
         response = MockResponse.new
         
@@ -43,5 +43,12 @@
         servlet.do_GET( request, response )
         
         response._verify
+    end
+    
+    def test_name_found
+        request = MockRequest.new
+        response = MockResponse.new
+        
+        servlet = AddressBookServlet.new( {} )
     end
 end

[MO-java-dev] CVS: no-stone-unturned/rubysrc addrservlet.rb,NONE,1.1 server.rb,NONE,1.1 tasks.txt,NONE,1.1 test_addrservlet.rb,NONE,1.1

[Nat P. <np...@us...>]

Update of /cvsroot/mockobjects/no-stone-unturned/rubysrc
In directory usw-pr-cvs1:/tmp/cvs-serv30449

Added Files:
	addrservlet.rb server.rb tasks.txt test_addrservlet.rb 
Log Message:
Added code of ruby example to CVS


--- NEW FILE: addrservlet.rb ---

require 'webrick'


class AddressBookServlet < WEBrick::HTTPServlet::AbstractServlet
    def do_GET( request, response )
        response['content-type'] = 'text/plain'
        response.body = 'no addresses found'
    end
end

--- NEW FILE: server.rb ---
#!/usr/bin/ruby

require 'webrick'
require 'addrservlet'

server = WEBrick::HTTPServer.new( :Port => 2000 )
server.mount( "/address", AddressBookServlet )

trap("INT") { server.shutdown }

server.start

--- NEW FILE: tasks.txt ---
Stories
1) anyone can search the entries in the book.
2) anyone can add their name and email address to the book.
3) anyone can remove an entry from the book.

Tasks

1a) accept a name and find no result
DONE

1b) accept a name and return a result from a hard-coded collection.
1c) Retrieve the entries from a file, specified as a servlet property.
    Values are held in memory.


--- NEW FILE: test_addrservlet.rb ---


require 'test/unit'
require 'webrick'
require 'addrservlet'


class MockRequest
end

class MockResponse
    include Test::Unit::Assertions
    
    def initialize
        @content_type_set = false
        @body_set = false
    end
    
    def []=( header, value )
        assert_equal( 'content-type', header )
        assert_match( /^text\/.*/, value )
        @content_type_set = true
    end
    
    def body=( value )
        assert_match( /no addresses found/, value )
        @body_set = true
    end
    
    def _verify
        assert( "content-type", @content_type_set )
        assert( "body", @body_set )
    end
end


class AddressBookServletTest < Test::Unit::TestCase
    def test_no_addresses_found
        request = MockRequest.new
        response = MockResponse.new
        
        servlet = AddressBookServlet.new( {} )
        servlet.do_GET( request, response )
        
        response._verify
    end
end

[MO-java-dev] CVS: no-stone-unturned/rubysrc - New directory

[Nat P. <np...@us...>]

Update of /cvsroot/mockobjects/no-stone-unturned/rubysrc
In directory usw-pr-cvs1:/tmp/cvs-serv30177/rubysrc

Log Message:
Directory /cvsroot/mockobjects/no-stone-unturned/rubysrc added to the repository

[MO-java-dev] CVS: no-stone-unturned/doc/xdocs a_longer_example.xml,1.2,1.3

[Nat P. <np...@us...>]

Update of /cvsroot/mockobjects/no-stone-unturned/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv28991

Modified Files:
	a_longer_example.xml 
Log Message:
Reordered story list at start to match order of sections.


Index: a_longer_example.xml
===================================================================
RCS file: /cvsroot/mockobjects/no-stone-unturned/doc/xdocs/a_longer_example.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- a_longer_example.xml	21 Aug 2002 23:49:40 -0000	1.2
+++ a_longer_example.xml	27 Aug 2002 19:17:33 -0000	1.3
@@ -12,10 +12,10 @@
 
     <itemizedlist>
       <listitem><para>
-        anyone can see all the entries in the book. The book is retrieved from a file.
+        anyone can search the entries in the book.
       </para></listitem>
       <listitem><para>
-        anyone can search the entries in the book.
+        anyone can see all the entries in the book. The book is retrieved from a file.
       </para></listitem>
       <listitem><para>
         anyone can add their name and email address to the book.

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

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

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

Modified Files:
	MockHttpServletRequest.java 
Log Message:
Added atrtibute support to servlet request


Index: MockHttpServletRequest.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet/MockHttpServletRequest.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- MockHttpServletRequest.java	16 Aug 2002 17:50:21 -0000	1.7
+++ MockHttpServletRequest.java	27 Aug 2002 16:38:17 -0000	1.8
@@ -37,6 +37,8 @@
     private final ExpectationValue myContentType = new ExpectationValue("content type");
     private final ExpectationList myGetAttributeNames = new ExpectationList("get attribute names");
 
+    private Vector myAttributesNames;
+
     public void setupGetAttribute(Object anAttributeToReturn) {
         myAttributesToReturn.addObjectToReturn(anAttributeToReturn);
     }
@@ -50,9 +52,12 @@
         return myAttributesToReturn.nextReturnObject();
     }
 
+    public void setupGetAttrubuteNames(Vector attributeNames){
+        myAttributesNames = attributeNames;
+    }
+    
     public Enumeration getAttributeNames() {
-        notImplemented();
-        return null;
+        return myAttributesNames.elements();
     }
 
     public String getAuthType() {

[MO-java-dev] CVS: mockobjects-java/src/j2ee/common/com/mockobjects/sql CommonMockDataSource.java,NONE,1.1

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

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

Added Files:
	CommonMockDataSource.java 
Log Message:
Added MockDataSource provided by Ted Husted


--- NEW FILE: CommonMockDataSource.java ---
package com.mockobjects.sql;

import java.io.PrintWriter;
import java.sql.Connection;
import javax.sql.DataSource;
import com.mockobjects.ExpectationCounter;
import com.mockobjects.MockObject;

/**
 * Abstract DataSource for use with mock testing.
 * Only the connection methods have been implemented here.
 * If testing of the log methods is needed, please submit a patch.
 * @see <a href="http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/sql/DataSource.html">javax.sql.DataSource</a>
 * @author Ted Husted
 * @version $Revision: 1.1 $ $Date: 2002/08/27 16:34:04 $
 */
public abstract class CommonMockDataSource extends MockObject
    implements DataSource {

    private Connection myConnection;

    private ExpectationCounter myConnectCalls =
        new ExpectationCounter("CommonMockDataSource.connection");

    /**
     * Register the number of connections the test should make.
     * The valid method will report any discrepancy with the
     * actual count.
     */
    public void setExpectedConnectCalls(int callCount) {
        myConnectCalls.setExpected(callCount);
    }

    /**
     * Pass the connection instance for use with tests.
     * This instance will be returned until replaced with another.
     */
    public void setupConnection(Connection aConnection) {
        myConnection = aConnection;
    }

// -------------------------------------------------------- implemented

    /**
     * Returns connection instance passed by setupConnection,
     * and increments the number of connect calls.
     */
    public Connection getConnection() {
        myConnectCalls.inc();
        return myConnection;
    }

// ------------------------------------------------------ notImplemented

    /**
     * Calls notImplemented. Returns null.
     */
    public Connection getConnection(String username,
        String password) {
        notImplemented();
        return null;
    }

    /**
     * Calls notImplemented. Returns 0.
     */
    public int getLoginTimeout() {
        notImplemented();
        return 0;
    }

    /**
     * Calls notImplemented. Returns null.
     */
    public PrintWriter getLogWriter()  {
        notImplemented();
        return null;
    }

    /**
     * Calls notImplemented.
     */
    public void setLoginTimeout(int seconds) {
        notImplemented();
    }

    /**
     * Calls notImplemented.
     */
    public void setLogWriter(PrintWriter out) {
        notImplemented();
    }
}


/*
 *
 * ====================================================================
 *
 * The Apache Software License, Version 1.1
 *
 * Copyright (c) 2002 The Apache Software Foundation.  All rights
 * reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in
 *    the documentation and/or other materials provided with the
 *    distribution.
 *
 * 3. The end-user documentation included with the redistribution, if
 *    any, must include the following acknowlegement:
 *       "This product includes software developed by the
 *        Apache Software Foundation (http://www.apache.org/)."
 *    Alternately, this acknowlegement may appear in the software itself,
 *    if and wherever such third-party acknowlegements normally appear.
 *
 * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
 *    Foundation" must not be used to endorse or promote products derived
 *    from this software without prior written permission. For written
 *    permission, please contact ap...@ap....
 *
 * 5. Products derived from this software may not be called "Apache"
 *    nor may "Apache" appear in their names without prior written
 *    permission of the Apache Group.
 *
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
 * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
 * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
 * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
 * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
 * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
 * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 * ====================================================================
 *
 * This software consists of voluntary contributions made by many
 * individuals on behalf of the Apache Software Foundation.  For more
 * information on the Apache Software Foundation, please see
 * <http://www.apache.org/>.
 *
 */

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.3/com/mockobjects/sql MockDataSource.java,NONE,1.1

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

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

Added Files:
	MockDataSource.java 
Log Message:
Added MockDataSource provided by Ted Husted


--- NEW FILE: MockDataSource.java ---
package com.mockobjects.sql;

/**
 * Empty implementation of <code>CommonMockDataSource</code>.
 * Implementations for later releases of Java (e.g. 1.4)
 * may include additional members.
 * @see <a href="http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/sql/DataSource.html">javax.sql.DataSource</a>
 * @author Ted Husted
 * @version $Revision: 1.1 $ $Date: 2002/08/27 16:34:03 $
 */
public class MockDataSource extends CommonMockDataSource{
}

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.4/com/mockobjects/sql MockDataSource.java,NONE,1.1

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

Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4/com/mockobjects/sql
In directory usw-pr-cvs1:/tmp/cvs-serv13537/src/j2ee/1.4/com/mockobjects/sql

Added Files:
	MockDataSource.java 
Log Message:
Added MockDataSource provided by Ted Husted


--- NEW FILE: MockDataSource.java ---
package com.mockobjects.sql;

/**
 * Empty implementation of <code>CommonMockDataSource</code>.
 * Implementations for later releases of Java
 * may include additional members.
 * @see <a href="http://java.sun.com/j2se/1.4.1/docs/api/javax/sql/DataSource.html">javax.sql.DataSource</a>
 * @author Ted Husted
 * @version $Revision: 1.1 $ $Date: 2002/08/27 16:34:04 $
 */
public class MockDataSource extends CommonMockDataSource{
}

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.4/com/mockobjects/sql - New directory

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

Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4/com/mockobjects/sql
In directory usw-pr-cvs1:/tmp/cvs-serv13127/src/j2ee/1.4/com/mockobjects/sql

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4/com/mockobjects/sql added to the repository

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.4/com/mockobjects - New directory

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

Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4/com/mockobjects
In directory usw-pr-cvs1:/tmp/cvs-serv13002/src/j2ee/1.4/com/mockobjects

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4/com/mockobjects added to the repository

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.4/com - New directory

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

Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4/com
In directory usw-pr-cvs1:/tmp/cvs-serv12817/src/j2ee/1.4/com

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4/com added to the repository

[MO-java-dev] CVS: mockobjects-java/src/j2ee/common/com/mockobjects/sql - New directory

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

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

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/src/j2ee/common/com/mockobjects/sql added to the repository

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.3/com/mockobjects/sql - New directory

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

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

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.3/com/mockobjects/sql added to the repository

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.4 - New directory

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

Update of /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4
In directory usw-pr-cvs1:/tmp/cvs-serv12628/src/j2ee/1.4

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.4 added to the repository

[MO-java-dev] CVS: mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet MockHttpSession.java,1.1,1.2

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

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

Modified Files:
	MockHttpSession.java 
Log Message:
Added setupGetAttributeNames and added notYetImplemented

Index: MockHttpSession.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet/MockHttpSession.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockHttpSession.java	23 Feb 2002 18:50:35 -0000	1.1
+++ MockHttpSession.java	27 Aug 2002 14:13:22 -0000	1.2
@@ -1,26 +1,36 @@
 package com.mockobjects.servlet;
 
-import javax.servlet.*;
-import javax.servlet.http.*;
-import java.util.*;
-import com.mockobjects.*;
+import java.util.Enumeration;
+import java.util.HashMap;
+
+import javax.servlet.ServletContext;
+import javax.servlet.http.HttpSession;
+import javax.servlet.http.HttpSessionContext;
+
+import org.omg.CORBA.PUBLIC_MEMBER;
+
+import com.mockobjects.ExpectationSet;
+import com.mockobjects.MapEntry;
+import com.mockobjects.MockObject;
+import com.mockobjects.Verifiable;
 
 public class MockHttpSession extends MockObject implements HttpSession, Verifiable {
-    public ExpectationSet myAttributes = new ExpectationSet("session attributes");
-    public HashMap attributes = new HashMap();
+    private ExpectationSet myAttributes = new ExpectationSet("session attributes");
+    private HashMap attributes = new HashMap();
+    private Enumeration attributeNames;
 
     private ServletContext servletContext;
 
-    public MockHttpSession() {
-        super();
-    }
-
     public Object getAttribute(String arg1) {
         return attributes.get(arg1);
     }
 
+    public void setupGetAttributeNames(Enumeration attributeNames) {
+        this.attributeNames = attributeNames;
+    }
+
     public Enumeration getAttributeNames() {
-        return null;
+        return attributeNames;
     }
 
     public long getCreationTime() {
@@ -39,10 +49,12 @@
     }
 
     public int getMaxInactiveInterval() {
+        notImplemented();
         return 0;
     }
 
     public HttpSessionContext getSessionContext() {
+        notImplemented();
         return null;
     }
 
@@ -59,25 +71,30 @@
         return null;
     }
 
-    public java.lang.String[] getValueNames() {
+    public String[] getValueNames() {
         notImplemented();
         return null;
     }
 
     public void invalidate() {
+        notImplemented();
     }
 
     public boolean isNew() {
+        notImplemented();
         return false;
     }
 
     public void putValue(String arg1, Object arg2) {
+        notImplemented();
     }
 
     public void removeAttribute(String arg1) {
+        notImplemented();
     }
 
     public void removeValue(String arg1) {
+        notImplemented();
     }
 
     public void setAttribute(String aKey, Object aValue) {
@@ -90,9 +107,6 @@
     }
 
     public void setMaxInactiveInterval(int arg1) {
-    }
-
-    public void verify() {
-        myAttributes.verify();
+        notImplemented();
     }
 }

Re: [MO-java-dev] Volunteer: Ted Husted

[Ted H. <hu...@ap...>]

The patch submitted for CommonDataSource shows what I think would be 
appropriate for a mock class.

-Ted.

Tim Mackinnon wrote:

>So Maybe - I (we?) need some examples of what java doc Ted feels needs
>adding. Maybe if he doesn't mind doing some doc for a class or two and we
>can have a look at it. It could be that we've missed something important
>that Ted has picked up on - however I think we agree that we don't want to
>do java doc just for java doc's sake right?
>
>Tim
>

Re: [MO-java-dev] javax.sql.DataSource

[Ted H. <hu...@ap...>]

Patch submiited.

Jeff Martin wrote:

>Yes, please send it in and I'll stick it somewhere.
>
>
>On Mon, 2002-08-26 at 23:08, Ted Husted wrote:
>
>>In creating a mock object for a JDBC utility, I found it useful to 
>>implement a mock DataSource.
>>
>>I didn't find one in the current API. Is this something that we would 
>>like to add?
>>
>>-Ted.
>>
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>cell phone?  Get a new here for FREE!
>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>_______________________________________________
>>Mockobjects-java-dev mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>>

RE: [MO-java-dev] Understanding alt.java.io?

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

On Mon, 2002-08-26 at 18:50, Tim Mackinnon wrote:
> Jeff - yep, you've answered the question.
> 
> I think my problem was, that by implementing the entire interface - it looks
> too close (I didn't spot the getRealFile method). Which while technically
> correct - can cause lots of confusion - the type inconsistency being the
> main one (I curse sun over and over for this mess!)

It can be a little confusing but it does have the advantage of allowing
it's use with the minimum of changes to existing code. Just change you
imports from java.io.* to alt.java.io.* and when you need the underlying
file call getRealFile(); although it's probably better to use
StreamFactory.createInputStream(alt.java.io.File)

> 
> For very low file stuff - I guess you may need all the methods, so your
> implementation would prove useful. Do you think there is a use for
> "SimpleXXXX" implementations that just leave most of the low level stuff
> that most people don't use anyway? I'm of two minds on this...

I've tried to take the same approach as I do with mocks in trying to
make them as dumb as possible. So the alt.* stuff is more along the
lines to patched versions to the Sun classes. I kinda feel that anything
else may become dangerously like a framework, which is not what we're
here for. 

> 
> By the way - this kind of decision I would agree would benefit from Java Doc
> :-)

:-)

> 
> Tim
> 
> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Jeff Martin
> Sent: 23 August 2002 15:56
> To: MockObjects
> Subject: Re: [MO-java-dev] Understanding alt.java.io?
> 
> 
> public java.io.File alt.java.io.File.getRealFile();
> 
> Was that the question?
> 
> On Fri, 2002-08-23 at 00:22, Tim Mackinnon wrote:
> > Guys - I don't understand how alt.java.io.File (the interface that sun
> > should have used in the first place) helps us mock stuff up?
> >
> > I must be missing something very obvious - but if I have a MockFile that
> > conforms to that interface, I can't use it with Sun's FileReader object
> > which expects a java.io.File (there is a basic type difference problem
> > here).
> >
> > So I guess I don't understand the point of it??? At connextra we have
> > subclassed things like java.io.Reader (as we did for some of the other io
> > classes - some of which live in the orginial mockobjects code base), and
> > have implemented the crucial methods that get it to work as a stub and a
> > mock. This way a MockReader can be used with a BufferedReader and you can
> > write relevent tests with it.
> >
> > For trickier classes like File - which really seem to require
> fileDescriptor
> > objects we have adopted the "SimpleFile" convention, which just wraps File
> > and just delegates a subset of the most useful methods. This interface
> also
> > provides  getFile, so that if you do use it at a low level in your code
> you
> > can get the File object and pass it to something like an XML Document
> class
> > (although we tend to use a MockReader in preference to the real file
> > anyway).
> >
> > Is alt.java.io.File an equivalent to the SimpleFile strategy? It doesn't
> > seem to be to me - so I am scratching my head trying to understand how its
> > being used in production code at the moment?
> >
> > With regards to some of this stuff, I promise to reintegrate asap to pass
> on
> > some of the stuff we have lurking around. Its taken us a long time to get
> > off visualAge so we can more easily work on open source projects (we are
> > almost there).
> >
> > Tim
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> --
> jeff martin
> information technologist
> mkodo limited
> 
> mobile: 44 (0) 78 5547 8331
> phone: 44 (0) 20 2226 4545
> email: je...@mk...
> 
> www.mkodo.com
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> 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.381 / Virus Database: 214 - Release Date: 02/08/2002
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com

Re: [MO-java-dev] Java Doc

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

On Mon, 2002-08-26 at 22:06, Nat Pryce wrote:
> Just to stick my oar in... the mock objects library is really divided
> into two parts, the core com.mockobjects package, which contains the
> expectation classes and MockObject base class, and then the packages of
> classes that mock actual APIs.  
> 
Actual there's now three. The alt tree which provides mockable versions
of unmockable classes.

This probably needs some java doc as it may not be totally apparent what
they're for. (See earlier discussion with Tim re alt.java.io.File)


> The com.mockobjects package is so simple that I have not found a need
> for documentation beyond the source and tests.  The other packages
> implement predefined interfaces (already documented by Sun, for
> example), and add setExpected... and setup... methods, the names of
> which follow strict conventions and are derived from the method and
> parameter names defined by the API.
> 
> The steepest part of the learning curve, in my experience, was learning
> the naming conventions and how to apply the com.mockobject classes to
> the mocking of my own interfaces.  The source to the mocked API packages
> was useful guidance.
> 
> So, perhaps it would be better to write some tutorial documents,
> explaining the naming conventions and how to use the classes in
> com.mockobjects to create new mocks.  There already is a document on
> naming conventions, but it is quite terse and the link is tucked away in
> the corner of the mock objects home page.
> 
> Cheers,
> 	Nat. 
> 
> -- 
> Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
> Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
> http://www.b13media.com
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com

Re: [MO-java-dev] javax.sql.DataSource

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

Yes, please send it in and I'll stick it somewhere.


On Mon, 2002-08-26 at 23:08, Ted Husted wrote:
> In creating a mock object for a JDBC utility, I found it useful to 
> implement a mock DataSource.
> 
> I didn't find one in the current API. Is this something that we would 
> like to add?
> 
> -Ted.
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com

[MO-java-dev] Defining Mock Objects

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

It occurred to me that it would be useful to share this message with
everyone in this group - as it fills in some history and thoughts.

Tim

------


Hi Russ -

You ask some good questions! We've been working with a few authors to
clarify some of this (Steve is in fact working on a book on the subject).

From a purist point of view I would say all 3 properties must be present.

However it might be useful to fill in some background for you - we didn't
just magically invent mock objects. Starting out with property 1, we found
we had tests with lots of "getters" on them - all doing assertEquals on some
property or another. We wanted to refactor them (to avoid duplication in our
tests) and had to choose between putting them in some test superclass or
putting them into the mock (although by our definition it was still a stub
at that point). Moving them into the mock felt cleaner (it has a more OO
feel to it, doesn't restrict you to test hierarchies and I'm not a big fan
of inheritance anyway).

So if you remove property 3, you will end up with lots of tests all having
the same assertions (in my experience anyway) and the danger that you missed
an important assertion as well. In the early days we were quite strict on
asserting every attribute - however after lots of usage we found that just
asserting on those attributes that you had set expectations on was a better
approach. If you are too strict your tests become a bit too complicated. In
this respect the much overlooked Expectation objects help you - they take
care of this policy automatically. (again this was all based on our
experience of writing lots of tests)

The previous paragraph now hints at property 2 - you need to know what to
assert on for your tests. In fact from a readability point of view -
specifying preconditions makes your test much more readable. It clearly
specifies that intent of the test. Having done this work - our experience
was that Fail fast came for free. When you are debugging your code, I would
say that fail fast is a god send - it gives you a way to imediately pop up a
debugger exactly when the problem occured - and with modern IDE's (eclipse,
visual age) you can even fix the problem and keep running. Steve often cites
an example of a financial product he was working on while we were still
discovering mock objects. They didn't have fail fast - and so had
complicated calculation tests that just had a "fail" message, with no way of
working out which of the stages of calculations had gone wrong.

Having said all of this - the Expectation objects do have a failLate flag -
which can be useful for "collection" style attributes where it can be
clearer to see the full collection of values at the end of the test (to
compare it with the expected list). I havent used this flag much - but it
did crop up once in our production code. (The topic of failing with useful
error messages is one which I covered in my XP2002 poster - A plea for
assertEquals - there are too many bad test examples out there).

I don't understand your point about "If the TestHelper isn't going to be
used repeatedly by the Class". Setting an expection on a Mock gives great
clarity. setExpectedDeleteRecord(1234) is a single interation with database
type object - but it would make a test very clear, and the failure message
would be extrememly useful. The test might bet be further enhanced with
setExpectedAddRecordCalls(0) to ensure that no adds happen in this test as
well (this is a patter I often see).

I also don't understand the point "If different tests have distinct
postconditions"? I think I may have covered this above - by setting
expectations on a mock you are effectively doing this. Actually we don't
really do postconditions in the sense you are hinting at - in that I don't
think I've written a verify that checks the state of an object to make sure
it matches a known condition. Of course you could do - and in this case to
stay general you would probably need to factor out some object to hold all
the states that you could check against (a different sort of expectation
object I guess, an ExpectationPostCondition?). However - you don't normally
need this becuase we are monitoring all the interactions coming in and can
"fail fast". Having said this - one topic we've never properly addressed is
message ordering - so an ExpectationPostCondition could be used for this
kind of thing... I quite like that now I think about it.

Hope this helps. And yes, if I was in the are, I would love to drop by. The
same applies to any of you guys if you are in London, get in touch or stop
the the ExtremeTuesdayClub and have a beer.

Tim

-----Original Message-----
From: Russ Rufer [mailto:ru...@pe...]
Sent: 23 August 2002 15:13
To: tim...@po...; st...@m3...; ph...@po...
Subject: Defining Mock Object


Hi,

I lead the Silicon Valley Patterns Group, a technical study group in
California.

We studied your Endo-Testing paper (and realted papers) over the last
two weeks, and we would really appreciate if you could help us with some
clarification.

The Endo-Testing paper never strictly defines what must be satisfied to
justify using the term Mock Object.

Crawling through the MockObject, Shunt, Stub, etc. pages on Wiki only
add to the confusion.

There seem to be three key ingredients:

(I'll use the name TestHelper to avoid conflicting with definitions I'm
trying to understand)

1: Provide an implementation of a TestHelper that your Class Under Test
   relies upon.  A simple implementation of the interface that
   contains minimal code required to interact with the Class
   Under Test for testing.

2: Fast Fail.  As soon as the Class Under Test attempts to interact
   with your TestHelper in an eroneous way, the TestHelper fails
   immediately, rather than hiding the problem until the test is
   over.

3: A verify() method on TestHelper that the test calls to check
   postconditions.

Clearly (1) is essential.  How about (2) and (3)?  Would you use the
term Mock Object if either of these were missing?

E.g. If the TestHelper isn't going to be used repeatedly by the Class
Under Test, failing fast (2) may not benefit your understanding of the
failure.

E.g. If different tests have distinct postconditions, the tests may be
simpler if you just extend the TestHelper with getters not on the
original interface.  In this case a uniform verify() method might just
be redundant--possibly empty.

Also, are there any other key elements to Mock Object that you would
want to include?

Thanks for any light you can shed on this for us.

BTW, if any of you find yourselves travelling to the Silicon Valley (or
the San Fransico Bay Area) you might enjoy joining a meeting of the
Silicon Valley Patterns Group.  Or it might just be fun to meet for
coffee or dinner while you're in the area.  If so, please feel free to
drop me a line.

- Russ Rufer
  Silicon Valley Patterns Group

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002

Re: [MO-java-dev] Java Doc

[Ted H. <hu...@ap...>]

Vincent Massol wrote:

>- overall architecture first (this is the overview.html and package.html
>javadoc for example - if we're staying javadoc land)
>- how the objects are linked together (that's the top level class
>comments)
>
>I agree that method level comments are useful only sporadically,
>

+1

For the next iteration of Struts, we'd like to base most of the 
documentation in  the "Developer Guides"  we've been publishing as 
package descriptions

http://jakarta.apache.org/struts/api/org/apache/struts/taglib/bean/package-summary.html#package_description

This way everything travels together and it's easier to keep it all in 
synch.

I'll look for an opportunity to starting putting something together for 
this project, but I like to do this sort of thing as I go and let it 
grow in the telling.

-Ted.

[MO-java-dev] javax.sql.DataSource

[Ted H. <hu...@ap...>]

In creating a mock object for a JDBC utility, I found it useful to 
implement a mock DataSource.

I didn't find one in the current API. Is this something that we would 
like to add?

-Ted.

RE: [MO-java-dev] Java Doc

[Vincent M. <vm...@oc...>]

+1 to that. 

But we also need an "architecture" document or a "user guide" document
that explains what an Expectation is (the probe notion), how it works,
that there is a core and what it provides, etc. This in addition better
naming conventions. I think the original paper is nice but too complex
to understand for a newcomer. We need something easier ...

-Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
Nat
> Pryce
> Sent: 26 August 2002 22:06
> To: Mockobjects-Java-Dev
> Subject: Re: [MO-java-dev] Java Doc
> 
> Just to stick my oar in... the mock objects library is really divided
> into two parts, the core com.mockobjects package, which contains the
> expectation classes and MockObject base class, and then the packages
of
> classes that mock actual APIs.
> 
> The com.mockobjects package is so simple that I have not found a need
> for documentation beyond the source and tests.  The other packages
> implement predefined interfaces (already documented by Sun, for
> example), and add setExpected... and setup... methods, the names of
> which follow strict conventions and are derived from the method and
> parameter names defined by the API.
> 
> The steepest part of the learning curve, in my experience, was
learning
> the naming conventions and how to apply the com.mockobject classes to
> the mocking of my own interfaces.  The source to the mocked API
packages
> was useful guidance.
> 
> So, perhaps it would be better to write some tutorial documents,
> explaining the naming conventions and how to use the classes in
> com.mockobjects to create new mocks.  There already is a document on
> naming conventions, but it is quite terse and the link is tucked away
in
> the corner of the mock objects home page.
> 
> Cheers,
> 	Nat.
> 
> --
> Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
> Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
> http://www.b13media.com
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

RE: [MO-java-dev] Java Doc

[Vincent M. <vm...@oc...>]

Tim,

I agree with almost all you have said. Here are a few comments though:

1/ Test case as documentation is good if you are yourself developing the
framework. If you're simply the user you probably don't want to bother
finding the test sources, installing them on your system and trying to
figure out some part of the implementations. What would be useful would
to copy the sample (aka the unit test :-)) in the generated javadoc (but
that's not very easy to do - I have thought about doing this for a
while).

2/ If I take a class named Control somewhere, I agree with you that I
don't want to know that getType() returns the type. However what I do
want to know is what a Control is. In what context is it used. The unit
tests will *not* tell me this, they simply tell me how to use it. But I
still lack the class level doc. So I think there is some margin for
useful doc. In mock objects, we need to explain to the user what an
Expectation is for example, even better with an example.

3/ You may be surprised that one of the rule I have given on my project
at work was to have javadoc for every single method! Even for the
getXXX() or setXXX() ones. The reasons are :

- our developers are not yet writing fined-grained unit tests

- writing comments still force you to ponder design ideas (in a lesser
way than writing unit tests *but* still better than nothing, and persons
still find it easier to write comments rather than refactor a piece of
code because it is badly written and thus cannot be easily tested using
mock objects)

- if we give the rule "only write comment where it is necessary" then
the result is obvious (this is proven stuff for us - we did it) :
nothing will get written. Moreover we cannot automatically check that
rule.

Thus the result is that we're using checkstyle with the javadoc checks
on and the build fails if javadoc is missing. At least it forces us not
to be lazy, think a bit about what our code does and *sometimes*
produces interesting comments! :-)

One more: we're working in a distributed team ... thus can't rely on
oral knowledge. 

I think (as Ted pointed out) that a lot of XP teams do not write
comments because they don't feel the need. The work in close and small
teams and are able to follow quite closely what's going on. In larger
groups, distributed groups, and frameworks, you really have "clients"
that need to understand the code that you have written. Tests are nice
but are really fine-grained and are only interesting if you already
understand the bigger picture, that is :
- overall architecture first (this is the overview.html and package.html
javadoc for example - if we're staying javadoc land)
- how the objects are linked together (that's the top level class
comments)

I agree that method level comments are useful only sporadically.

Time to go to bed ... :-)

Cheers,
-Vincent

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
Tim
> Mackinnon
> Sent: 26 August 2002 19:52
> To: Mockobjects-Java-Dev
> Subject: [MO-java-dev] Java Doc
> 
> Hmmm - have seen this before at OTI where (when I was there many years
> ago)
> we were required to put a method comment on public methods (and this
was
> all
> highly disciplined people) - and generally the method and names of the
> paramters were all that was needed. I often wanted to write "Does just
as
> it
> says on the tin"!
> 
> If not - renaming the method is usually a better fix than writing the
doc?
> 
> The only type of comment needed might be the range of the paramaters -
but
> then I think that the tests of a method more reliably document this.
And
> if
> you've got tests - why create more work by duplicated them in non-
> executable
> code? Maybe a tool to autogenerate the comments would be an answer for
> those
> who don't have good IDE's. We could just ship a little program with
the
> source code - DocGenerator.exe (that would be more useful).  Of course
-
> there is sometimes a policy decision, or workaround that does require
> documentation, and in this respect Ted is right. But for the mindless
> stuff - docgenerator may be a better answer?
> 
> 
> For example -  I have just randomly picked a Java class from the
javadoc
> that I didn't know anything about "Control". The constructor has:
> 
> Control(Control.Type type)
>           Constructs a Control with the specified type.
> 
> and methods:
> 
> Control.Type getType()
>           Obtains the control's type.
> 
> String toString()
>           Obtains a String describing the control type and its current
> state.
> 
> 
> This isn't very useful is it??? There are lots of examples of this -
> although once in a while there is a useful doc e.g. (InputStream)
> 
> public abstract int read()
>                   throws IOExceptionReads the next byte of data from
the
> input stream. The value byte is returned as an int in the range 0 to
255.
> If
> no byte is available because the end of the stream has been reached,
the
> value -1 is returned. This method blocks until input data is
available,
> the
> end of the stream is detected, or an exception is thrown.
> 
> Anyway - I'll stop now :-)
> 
> 
> Tim
> 
> -----Original Message-----
> From: Shellman, Joel [mailto:Joe...@su...]
> Sent: 26 August 2002 18:27
> To: tim...@po...
> Subject: RE: [MO-java-dev] Volunteer: Ted Husted
> 
> 
> > I wouldn't want to see the mock objects project go the way of the
SUN
> > JavaDoc which is quite frankly useless!!! At the method level the
doc
> simply
> > states everything that the method signature gives - what a waste of
> energy.
> 
> How ironic. I was just reading Sun's guidelines for writting JavaDoc
and
> they specifically stated that the JavaDoc should not state what is
already
> in the method signature.
> 
> Joel Shellman
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.381 / Virus Database: 214 - Release Date: 02/08/2002
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev