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

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

[<moc...@li...>]

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

Modified Files:
	MockPreparedStatement.java 
Log Message:
minor additions to API

Index: MockPreparedStatement.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/sql/MockPreparedStatement.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockPreparedStatement.java	2001/07/29 19:50:24	1.1
+++ MockPreparedStatement.java	2001/11/17 10:16:56	1.2
@@ -28,13 +28,6 @@
         }
     }
 
-    public void verify() {
-        super.verify();
-        mySetParameters.verify();
-        myExecuteCalls.verify();
-        myClearParametersCalls.verify();
-    }
-
     public void clearParameters() throws SQLException {
         myClearParametersCalls.inc();
     }

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

[<moc...@li...>]

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

Modified Files:
	MockServletOutputStream.java 
Log Message:
minor additions to API

Index: MockServletOutputStream.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/servlet/MockServletOutputStream.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockServletOutputStream.java	2001/07/29 19:50:24	1.1
+++ MockServletOutputStream.java	2001/11/17 10:16:56	1.2
@@ -1,28 +1,22 @@
 package com.mockobjects.servlet;
 
-import com.mockobjects.*;
-import junit.framework.*;
-import javax.servlet.*;
-import java.io.*;
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import javax.servlet.ServletOutputStream;
+import com.mockobjects.ExpectationCounter;
+import com.mockobjects.ExpectationValue;
 
 public class MockServletOutputStream extends ServletOutputStream {
     private ExpectationValue myWriteCalled = new ExpectationValue("MockServletOutputStream.write()");
     private boolean myThrowException = false;
     private ExpectationCounter myCloseCallCount = new ExpectationCounter("MockServletOutputstream.close()");
-    private ByteArrayOutputStream myBuffer = new ByteArrayOutputStream();
+    private ByteArrayOutputStream myBuffer;
 
     public MockServletOutputStream() {
         super();
+        setupClearContents();
     }
 
-    public void close() throws IOException {
-        myCloseCallCount.inc();
-    }
-
-    public String getContents() {
-        return myBuffer.toString();
-    }
-
     public void setExpectedCloseCalls(int closeCall) {
         myCloseCallCount.setExpected(closeCall);
     }
@@ -35,19 +29,31 @@
         myThrowException = throwException;
     }
 
-    public String toString() {
-        return getContents();
+    public void close() throws IOException {
+        myCloseCallCount.inc();
     }
 
-    public void verify() {
-        myWriteCalled.verify();
-        myCloseCallCount.verify();
+    public String toString() {
+        return getContents();
     }
 
     public void write(int b) throws IOException {
+        myWriteCalled.setActual(true);
         if (myThrowException)
             throw new IOException("Test IOException generated by request");
         myBuffer.write(b);
-        myWriteCalled.setActual(true);
+    }
+
+    public void setupClearContents () {
+        myBuffer = new ByteArrayOutputStream();
+    }
+
+    public String getContents() {
+        return myBuffer.toString();
+    }
+
+    public void verify() {
+        myWriteCalled.verify();
+        myCloseCallCount.verify();
     }
 }

[MO-java-dev] CVS: mockobjects-java/src/examples/com/mockobjects/examples/mailinglist TestMailingList.java,1.10,1.11

[<moc...@li...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/examples/com/mockobjects/examples/mailinglist
In directory usw-pr-cvs1:/tmp/cvs-serv29129/examples/com/mockobjects/examples/mailinglist

Modified Files:
	TestMailingList.java 
Log Message:
minor additions to API

Index: TestMailingList.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/examples/com/mockobjects/examples/mailinglist/TestMailingList.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- TestMailingList.java	2001/08/27 02:42:54	1.10
+++ TestMailingList.java	2001/11/17 10:16:56	1.11
@@ -25,7 +25,7 @@
     private MockStatement mockStatement = new MockStatement();
 
     public void setUp() {
-        mockConnection.setupPreparedStatement(mockPreparedStatement);
+        mockConnection.setupAddPreparedStatement(mockPreparedStatement);
         mockConnection.setupStatement(mockStatement);
     }
 
@@ -55,7 +55,7 @@
     public void testPrepareStatementFailsForAdd() throws MailingListException {
         mockConnection.setupThrowExceptionOnPrepareOrCreate(new SQLException("MockConnection"));
 
-        mockConnection.setExpectedPrepareStatementString(MailingList.INSERT_SQL);
+        mockConnection.addExpectedPreparedStatementString(MailingList.INSERT_SQL);
         mockPreparedStatement.setExpectedExecuteCalls(0);
         mockPreparedStatement.setExpectedCloseCalls(0);
 
@@ -227,7 +227,7 @@
     }
 
     private void setExpectationsForPreparedStatement(String sqlStatement) {
-        mockConnection.setExpectedPrepareStatementString(sqlStatement);
+        mockConnection.addExpectedPreparedStatementString(sqlStatement);
         mockPreparedStatement.setExpectedExecuteCalls(1);
         mockPreparedStatement.setExpectedCloseCalls(1);
     }

Re: [MO-java-dev] SQL validation

[<moc...@li...>]

RnJvbTogIkdyZWcgTWVycmlsbCIgPGdyZWdobWVycmlsbEB5YWhvby5jb20+DQo+IE15IHF1ZXN0
aW9uIHRvIHRoaXMgbGlzdCBpczogd291bGQgYW55b25lIGJlDQo+IGludGVyZXN0ZWQgaW4gYW4g
b3B0aW9uYWwgU1FMIHZhbGlkYXRpb24gZmVhdHVyZSBvbg0KPiByZWxldmFudCBtb2NrIHNxbCBv
YmplY3RzDQo+IChNb2NrU3RhdGVtZW50L01vY2tQcmVwYXJlZFN0YXRlbWVudCk/ICBTb21ldGhp
bmcNCj4gYWxvbmcgdGhlIGxpbmVzIG9mIHNldEV4cGVjdFZhbGlkU1FMKGJvb2xlYW4pPyAgV2hl
bg0KPiB0cnVlLCB0aGlzIHByb3BlcnR5IHdvdWxkIHZhbGlkYXRlIHRoZSBzeW50YXggb2YgU1FM
DQo+IHN0YXRlbWVudHMgb24gY2FsbHMgdG8gZXhlY3V0ZVVwZGF0ZSgpICYNCj4gZXhlY3V0ZVF1
ZXJ5KCkuICBWZXJ5IGhhbmR5IHRvIGVuc3VyZSB0aGF0DQo+IGR5bmFtaWNhbGx5LWdlbmVyYXRl
ZCBxdWVyaWVzIGRvbid0IGhhdmUgc3ludGF4DQo+IHByb2JsZW1zLg0KPiANCj4gQW5kIHRoZSBi
b3R0b20gbGluZSAtIGRvZXMgYmFzaWMgU1FMIHZhbGlkYXRpb24gaGF2ZSBhDQo+IHBsYWNlIGlu
IE1vY2tPYmplY3Qtc3R5bGUgdW5pdCB0ZXN0aW5nPyAgT3Igc2hvdWxkDQo+IHRoaXMgdHlwZSBv
ZiByZXNwb25zaWJpbGlsdHkgbGllIHdpdGggZnVuY3Rpb25hbA0KPiB0ZXN0aW5nLCBzaW5jZSB0
aGUgU1FMIHZhbGlkYXRpb24gd2hpY2ggaXMgYWN0dWFsbHkNCj4gZG9uZSBhdCBydW50aW1lIGlz
IGRhdGFiYXNlLWRlcGVuZGVudD8NCg0KbXkgKGRvdWJ0bGVzcyBuYWl2ZSkgdGFrZSBvbiB0aGlz
IGlzIHRoYXQgaXMgdGhhdCBtb3N0IFNRTCBpcyBlaXRoZXIgc2ltcGxlIChwb3AgYSBjb3VwbGUg
b2YgdmFsdWVzIGluIGEgcXVlcnkpIG9yIGRyZWFkZnVsbHkgY29tcGxpY2F0ZWQuIEZvciB0aGUg
Zm9ybWVyLCBhbGwgeW91IHJlYWxseSBuZWVkIHRvIGNoZWNrIF9pbiB0aGUgdW5pdCB0ZXN0XyBp
cyB0aGF0IHRoZSByaWdodCB2YWx1ZXMgZ2V0IHBhc3NlZCB0aHJvdWdoLCB3aGljaCB5b3UgY2Fu
IHByb2JhYmx5IGRvIHdpdGggYSBzaW1wbGUgc3Vic3RyaW5nIG1hdGNoLiBUaGVyZSdzIGEgYml0
IG9mIGFuIGFydCB0byBzcGVjaWZpeWluZyB0aGUgbWluaW11bSB0aGF0IGlzIGltcG9ydGFudCBp
biBhIHVuaXQgdGVzdC4gRm9yIHRoZSBsYXR0ZXIsIHlvdSBwcm9iYWJseSB3YW50IGEgc2VwYXJh
dGUgb2JqZWN0IHRvIGdlbmVyYXRlIHRoZSBTUUwgd2hpY2ggd291bGQgYmUgdGVzdGVkIGF3YXkg
ZnJvbSB0aGUgSkRCQyAtLSBpbiB3aGljaCBjYXNlIHlvdXIgcGFyc2VyIG1pZ2h0IGJlIGFwcHJv
cHJpYXRlLg0KDQpPZiBjb3Vyc2UsIHRoaXMga2luZCBvZiBkZXZlbG9wbWVudCBhbHNvIHJlcXVp
cmVzIGEgaGlnaGVyLWxldmVsIHRlc3QgdG8gbWFrZSBzdXJlIHlvdSBoYXZlbid0IGRyaWZ0ZWQg
YXdheSBmcm9tIHRoZSBzY2hlbWEuIEZvciBhIHNtYWxsIGFwcGxpY2F0aW9uLCB0aGF0IHdvdWxk
IHByb2JhYmx5IGJlIHlvdXIgYWNjZXB0YW5jZSB0ZXN0cyAob3Igd2hhdGV2ZXIgd2UncmUgY2Fs
bGluZyB0aGVtIG5vdykuIEZvciBhIGxhcmdlIGFwcGxpY2F0aW9uLCB5b3UgbWlnaHQgaGF2ZSBz
b21lIERCIGludGVncmF0aW9uIHRlc3RzLg0KDQp0aGUgb3RoZXIgdGhvdWdodCB0aGF0IHN0cmlr
ZXMgbWUgaXMgdGhhdCB3ZSBrbm93IHRoYXQgdGVzdC1maXJzdCBjaGFuZ2VzIHRoZSB3YXkgd2Ug
d3JpdGUgb3VyIGNvZGUgKHRvIG1ha2UgaXQgdGVzdGFibGUpLiBJIHdvdWxkIGV4cGVjdCB0aGF0
IHdyaXRpbmcgZGIgYWNjZXNzIGZvciB0ZXN0YWJpbGl0eSB3b3VsZCBjaGFuZ2UgdGhlIHdheSB3
ZSB3cml0ZSBTUUwuIEhhcyBhbnlvbmUgbm90aWNlZCB0aGlzPw0KDQo+IEkndmUgY3JlYXRlZCBh
IHByb3RvdHlwZSBvZiBzdWNoIGEgZmVhdHVyZSwgdXNpbmcgYQ0KPiBwYXJzZXIgZ2VuZXJhdGVk
IHdpdGggSmF2YUNDIGFuZCBhIGNvbnRyaWJ1dGVkIGdyYW1tYXINCj4gKGh0dHA6Ly93d3cuY29i
YXNlLmNzLnVjbGEuZWR1L3B1Yi9qYXZhY2MvKS4gIEl0IHNlZW1zDQo+IHRvIHdvcmsgT0suICAo
VGhlIGdyYW1tYXIgaXMgYSBsaXR0bGUgT3JhY2xlLXNwZWNpZmljLA0KPiBidXQgc2hvdWxkIGhh
bmRsZSBzdGFuZGFyZCBTUUwganVzdCBmaW5lLikNCj4gDQo+IERvIHlvdSB0aGluayB0aGlzIGtp
bmQgb2YgZmVhdHVyZSB3b3VsZCBmaXQgd2VsbCBpbg0KPiB0aGUgbW9jayBvYmplY3RzIGNvcmU/
ICBPciBkb2VzIGl0IHNlZW0gbW9yZSBsaWtlIGFuDQo+IG9wdGlvbmFsIGZlYXR1cmUgd2hpY2gg
c2hvdWxkIGJlIHJlbGVhc2VkL21haW50YWluZWQNCj4gc2VwYXJhdGVseT8gIA0KDQpJdCBzb3Vu
ZHMgbGlrZSBhIHNlcGFyYXRlIGZlYXR1cmUgdG8gbWUuIERvIHBlb3BsZSB0aGluayBpdCBzaG91
bGQgYmUgaG9zdGVkIG9uIHRoZSBNb2NrIE9iamVjdHMgcHJvamVjdD8NCg0KU3RldmUNCg0K

Re: [MO-java-dev] [CONTRIB] Mock for PropertyChangelistener

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

RnJvbTogPHJpbmdvLmRlc21ldEBtZWRpYWdlbml4LmNvbT4NCj4gV291bGQgaXQgYmUgYSBnb29k
IGlkZWEgdG8ganVzdCBiZSBhYmxlIHRvIHNldCB0aGUgZXhwZWN0ZWQgZXZlbnQgb2JqZWN0cyBv
bg0KPiB0aGUgTW9ja1Byb3BlcnR5Q2hhbmdlTGlzdGVuZXIgYW5kIGhhdmUgdGhlIGV4cGVjdGVk
IGV2ZW50Q291bnQgcmVtb3ZlZCBmcm9tDQo+IHRoZSBjbGFzcz8gVGhlIG5yIG9mIGV4cGVjdGVk
IGV2ZW50cyBzaG91bGQgdGhlbiBoYXZlIHRvIG1hdGNoIHRoZSBudW1iZXIgb2YNCj4gZXZlbnQg
b2JqZWN0cyB5b3UgYWRkIHRvIHRoZSBtb2NrIGxpc3RlbmVyIGFzIGV4cGVjdGVkLg0KDQp5ZXMu
DQoNCj4gSXNuJ3QgdGhlcmUganVzdCBvbmx5IHdheSB0byBtYXRjaCBhbiBleHBlY3RlZCBQcm9w
ZXJ0eUNoYW5nZUV2ZW50IHdpdGggdGhlDQo+IGFjdHVhbCBvbmU/IE9yIHdvdWxkIHRoZSBFdmVu
dE1hdGNoIGNsYXNzIGJlIHRoZSBzdXBlcmNsYXNzIG9mIGUuZy4NCj4gUHJvcGVydHlDaGFuZ2VF
dmVudE1hdGNoLCBMaXN0RGF0YUV2ZW50TWF0Y2gsIGV0Yy4uLiB3aGVyZWluIHRoZSBhY3R1YWwN
Cj4gY29tcGFyaXNvbiBvZiB0aGUgZXhwZWN0ZWQgZXZlbnQgdHlwZSB3aXRoIGl0cyBhY3R1YWwg
dmFsdWUgaGFwcGVucz8NCg0KSWYsIGFzIGluIHRoaXMgY2FzZSwgeW91IGtub3cgdGhhdCB0aGUg
ZXF1YWxzIG1ldGhvZCB3aWxsIGJlIGNhbGxlZCBvbiB0aGUgRXZlbnRNYXRjaCBvYmplY3QsIHJh
dGhlciB0aGFuIHRoZSBwcm9wZXJ0eSBjaGFuZ2UgZXZlbnQsIHlvdSBjYW4gaW1wbGVtZW50IGl0
IHRvIG1ha2Ugd2hhdGV2ZXIgY29tcGFyaXNvbnMgeW91J3JlIGludGVyZXN0ZWQgaW4uIEZvciBl
eGFtcGxlOiANCg0KICBib29sZWFuIEV2ZW50TWF0Y2hlci5lcXVhbHMoT2JqZWN0IGFuT2JqZWN0
KSB7DQogICAgaWYgKCFhbk9iamVjdCBpbnN0YW5jZW9mIFByb3BlcnR5Q2hhbmdlRXZlbnQpIHsN
CiAgICAgIHJldHVybiBmYWxzZTsNCiAgICB9DQogICAgUHJvcGVydHlDaGFuZ2VFdmVudCBldmVu
dCA9IChQcm9wZXJ0eUNoYW5nZUV2ZW50KWFuT2JqZWN0Ow0KDQogICAgaWYgKG51bGwgIT0gdGhp
cy5wcm9wZXJ0eU5hbWUgJiYgISB0aGlzLnByb3BlcnR5TmFtZS5lcXVhbHMoZXZlbnQuZ2V0UHJv
cGVydHlOYW1lKCkpKSB7DQogICAgIHJldHVybiBmYWxzZTsNCiAgICB9DQogICAgWy4uLiBvciB3
aGF0ZXZlciAuLi5dDQogIH0NCg0KT2YgY291cnNlLCB0aGUgbWluaW1hbCBjYXNlIGlzIGp1c3Qg
dG8gY2hlY2sgdGhhdCB0aGUgaW5jb21pbmcgb2JqZWN0IGlzIGEgUHJvcGVydHlDaGFuZ2VFdmVu
dCwgd2hpY2ggaW1wbGVtZW50cyB5b3VyIGlkZWEgYWJvdmUuDQoNClN0ZXZlDQoNCg==

Re: [MO-java-dev] com.mockobjects.sql.*

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

PiBIaSBhbGwgaW4gREVWIHdvcmxkICENCg0KV2VsY29tZS4NCiANCj4gSSBoYXZlIHNvbWUgcXVl
c3Rpb25zLg0KPiANCj4gMS4gV2h5IHRoZSBNb2NrUmVzdWx0U2V0IGRvZXMgbm90IGhhbmRsZSBj
b3JyZWN0bHkgbnVsbCB2YWx1ZXMNCj4gICAgIGluIG1ldGhvZHMgZ2V0PHByaW1pdGl2ZSB0eXBl
PigpID8gQWxzbyB0aGUgd2FzTnVsbCgpIG1ldGhvZA0KPiAgICAgaXMgbm90IHN1cHBvcnRlZC4g
SSB0aGluayBpdCBpcyBub3QgZGlmZmVyZW50IHRvIGltcGxlbWVudCBzdWNoDQo+ICAgICB0aGlu
Z3MuIE1vcmVvdmVyIHRoZSBqYXZhLnNxbC5SZXN1bHRTZXQgaW50ZXJmYWNlIHNwZWNpZmljYXRp
b24NCj4gICAgIHN0cm9uZ2x5IGRlZmluZXMgdGhlIHZhbHVlcywgd2ljaCBtdXN0IGJlIHJldHVy
bmVkIGluIG51bGwgY2FzZS4NCg0KWW91J3JlIHJpZ2h0IHRoYXQgaXQncyBub3QgZGlmZmljdWx0
LiBXZSBoYXZlbid0IGltcGxlbWVudGVkIHRoZXNlIGJlY2F1c2Ugd2UgaGF2ZW4ndCBuZWVkZWQg
dGhlbSBpbiBvdXIgd29yayBzbyBmYXIuIElmIHlvdSBuZWVkIHRoZW0sIHRoZW4gcGxlYXNlIGRv
IHNvIGFuZCBjb250cmlidXRlIHRoZW0gYmFjayB0byB0aGUgcHJvamVjdC4NCg0KPiAyLiBXaHkg
dGhlIE1vY2tDb25uZWN0aW9uIGRvZXMgbm90IHN1cHBvcnRzIHRoZSBpc0Nsb3NlZCgpIG1ldGhv
ZCA/DQo+ICAgICBPbmNlIHRoZSBjbG9zZSgpIG1ldGhvZCBjYWxsZWQgdGhlIGlzQ2xvc2VkKCkg
bWV0aG9kIG11c3QgcmV0dXJuIGZhbHNlLg0KPiAgICAgSSB0aGluayB0aGlzIGlzIGEgdmVyeSBz
aW1sZSBiZWhhdmlvci4NCg0KU2VlIGFib3ZlLg0KDQo+IDMuIFRoZSBNb2NrQ29ubmVjdGlvbiBk
b2VzIG5vdCBzdXBwb3J0cyBtdWx0aXBseSBQcmVwYXJlZFN0YXRlbWVudHMgc2V0dXAuDQo+ICAg
ICBJdCBhbHdheXMgcmV0dXJuIHRoZSBzYW1lIFByZXBhcmVkU3RhdGVtZW50IChpZiB3YXMgc2V0
IHVwKS4gVGhpcyBjbGFzcw0KPiBpcyBub3QNCj4gICAgIHVzZWZ1bCBpbiBtYW55IGNhc2VzIGJl
Y2F1c2Ugb2YgdGhpcyBiZWhhdmlvci4NCj4gICAgIEkgaGF2ZSB3cml0ZWQgdGhlIE1vY2tNUFND
b25uZWN0aW9uIHdoaWNoIHN1cG9ydHMgdGhpcyBmZWF0dXJlIGFuZA0KPiByZXR1cm5zDQo+ICAg
ICB0aGUgUHJlcGFyZWRTdGF0ZW1lbnRzIHNlcXVlbmNseSBieSBjYWxsaW5nIHByZXBhcmVTdGF0
ZW1lbnQoKSBtZXRob2QuDQo+ICAgICBJIGNhbiBwb3N0IGhlcmUgdGhlIGltcGxlbWVudGF0aW9u
Lg0KDQpIYXZlIHlvdSBjaGVja2VkIHRoZSBDVlMgcmVwb3NpdG9yeT8gVGhlIHB1YmxpYyBidWls
ZCBpcyBzb21ld2hhdCBvdXQgb2YgZGF0ZSwgYnV0IHRoZSByZXBvc2l0b3J5IHZlcnNpb24gc3Vw
cG9ydHMgbXVsdGlwbGUgc3RhdGVtZW50cy4NCiANCldlJ3ZlIGJlZW4gYWRkaW5nIGZ1bmN0aW9u
YWxpdHkgaW5jcmVtZW50YWxseSBhcyBvdXIgbmVlZHMgYXJpc2UsIGJlY2F1c2UgaXQgd291bGQg
aGF2ZSB0YWtlbiBmb3JldmVyIHRvIGltcGxlbWVudCBldmVyeXRoaW5nLiBXZSdyZSB2ZXJ5IGhh
cHB5IHRvIGFjY2VwdCBwYXRjaGVzIGZyb20gcGVvcGxlIHdobyBoYXZlIGFkZGl0aW9uYWwgcmVx
dWlyZW1lbnRzLg0KDQpTdGV2ZQ0KDQoNCg==

RE: [MO-java-dev] SQL validation

[Vincent T. <Vin...@ge...>]

One easy thing to do to complement your MockObjects testing is to test your
expected SQL query string against the DB with a simple SQL query analyzer.
Once you are sure of your syntax (providing that your table definition
doesnt change) you can rely on MockObjects testing until functional testing.
That's what we do and it hasn't reserved any bad surprise ... yet :-)

 -Vincent-

-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Greg Merrill
Sent: Friday, November 16, 2001 4:29 PM
To: moc...@li...
Subject: [MO-java-dev] SQL validation


I recently had a brief discussion with a couple of
developers on the c2 wiki
(http://c2.com/cgi/wiki?MockObject) regarding database
testing & MockObjects.  Here is an excerpt:

<excerpt>
I'm curious - for those of you out there who are using
MockObjects to test JDBC code, do you typically have
at least one unit test which uses a "real" database
connection as a santiy check? Or do you keep live
connections out of the unit testing altogether,
letting this type of testing fall under the umbrella
of "functional testing"? While I like the speed and
focus of MockObjects for database testing, certain
things about it make me nervous, e.g. SQL statements
are not validated. --GregMerrill

I'm currently getting big into database mock objects
with VbUnitThree. I'm currently ignoring the issue of
testing the real database objects. But I know this is
a mistake; I'll have to come back and write unit tests
for them, just like any other class. -- JeffGrigg

OK, it bit me today: My unit tests didn't test the
SQL, and so didn't catch a stray column. But that's
OK, because the end-to-end functional tests (done in
the same unit testing framework, only less often),
caught the problem. No blood; no foul. (Yes, I still
need to write unit tests for the SQL. I will, I
will... ;-) -- jtg
</excerpt>

My question to this list is: would anyone be
interested in an optional SQL validation feature on
relevant mock sql objects
(MockStatement/MockPreparedStatement)?  Something
along the lines of setExpectValidSQL(boolean)?  When
true, this property would validate the syntax of SQL
statements on calls to executeUpdate() &
executeQuery().  Very handy to ensure that
dynamically-generated queries don't have syntax
problems.

I've created a prototype of such a feature, using a
parser generated with JavaCC and a contributed grammar
(http://www.cobase.cs.ucla.edu/pub/javacc/).  It seems
to work OK.  (The grammar is a little Oracle-specific,
but should handle standard SQL just fine.)

Do you think this kind of feature would fit well in
the mock objects core?  Or does it seem more like an
optional feature which should be released/maintained
separately?

And the bottom line - does basic SQL validation have a
place in MockObject-style unit testing?  Or should
this type of responsibililty lie with functional
testing, since the SQL validation which is actually
done at runtime is database-dependent?

-Greg Merrill


__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

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

[MO-java-dev] SQL validation

[Greg M. <gre...@ya...>]

I recently had a brief discussion with a couple of
developers on the c2 wiki
(http://c2.com/cgi/wiki?MockObject) regarding database
testing & MockObjects.  Here is an excerpt:

<excerpt>
I'm curious - for those of you out there who are using
MockObjects to test JDBC code, do you typically have
at least one unit test which uses a "real" database
connection as a santiy check? Or do you keep live
connections out of the unit testing altogether,
letting this type of testing fall under the umbrella
of "functional testing"? While I like the speed and
focus of MockObjects for database testing, certain
things about it make me nervous, e.g. SQL statements
are not validated. --GregMerrill 

I'm currently getting big into database mock objects
with VbUnitThree. I'm currently ignoring the issue of
testing the real database objects. But I know this is
a mistake; I'll have to come back and write unit tests
for them, just like any other class. -- JeffGrigg 

OK, it bit me today: My unit tests didn't test the
SQL, and so didn't catch a stray column. But that's
OK, because the end-to-end functional tests (done in
the same unit testing framework, only less often),
caught the problem. No blood; no foul. (Yes, I still
need to write unit tests for the SQL. I will, I
will... ;-) -- jtg 
</excerpt>

My question to this list is: would anyone be
interested in an optional SQL validation feature on
relevant mock sql objects
(MockStatement/MockPreparedStatement)?  Something
along the lines of setExpectValidSQL(boolean)?  When
true, this property would validate the syntax of SQL
statements on calls to executeUpdate() &
executeQuery().  Very handy to ensure that
dynamically-generated queries don't have syntax
problems.

I've created a prototype of such a feature, using a
parser generated with JavaCC and a contributed grammar
(http://www.cobase.cs.ucla.edu/pub/javacc/).  It seems
to work OK.  (The grammar is a little Oracle-specific,
but should handle standard SQL just fine.)

Do you think this kind of feature would fit well in
the mock objects core?  Or does it seem more like an
optional feature which should be released/maintained
separately?  

And the bottom line - does basic SQL validation have a
place in MockObject-style unit testing?  Or should
this type of responsibililty lie with functional
testing, since the SQL validation which is actually
done at runtime is database-dependent?

-Greg Merrill


__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

[MO-java-dev] com.mockobjects.sql.*

[Egor S. <sl...@ac...>]

Hi all in DEV world !

I have some questions.

1. Why the MockResultSet does not handle correctly null values
    in methods get<primitive type>() ? Also the wasNull() method
    is not supported. I think it is not different to implement such
    things. Moreover the java.sql.ResultSet interface specification
    strongly defines the values, wich must be returned in null case.

2. Why the MockConnection does not supports the isClosed() method ?
    Once the close() method called the isClosed() method must return false.
    I think this is a very simle behavior.

3. The MockConnection does not supports multiply PreparedStatements setup.
    It always return the same PreparedStatement (if was set up). This class
is not
    useful in many cases because of this behavior.
    I have writed the MockMPSConnection which suports this feature and
returns
    the PreparedStatements sequencly by calling prepareStatement() method.
    I can post here the implementation.

I also have writed corresponding subclasses to resolve 1st and 2nd problems,
but i think that these changes must be implemented in MockResultSet and
MockConnection classes.



With best regards,
Egor Samarkhanov (sl...@ac...)
Software Engineer
Actimind, Inc.
tel 7-812-325-87-16

RE: [MO-java-dev] [CONTRIB] Mock for PropertyChangelistener

[<rin...@me...>]

Hello Steve,

> > I have used this class for multiple events, but the only 
> thing I verify on
> > the mock listener at that moment is the number of events 
> received, not the
> > actual data of each event.
> 
> Then I'd recommend taking out the stuff you don't use. Unless 
> someone else does.

Would it be a good idea to just be able to set the expected event objects on
the MockPropertyChangeListener and have the expected eventCount removed from
the class? The nr of expected events should then have to match the number of
event objects you add to the mock listener as expected.

> > Tell me if my thoughts match yours: the 
> MockPropertyChangeListener maintains
> > a list of EventMatch objects, in the order I expect each 
> event. When I add
> > an EventMatch object to the mock listener, the EventMatch 
> object contains a
> > fully configured PropertyChangeEvent as the expected event. When the
> > propertyChangeEvent on the mock listener is invoked, it 
> takes the actual
> > event and pushes it to the EventMatch object, increments 
> the eventCount
> > expectation. A subsequent call will push the actual event 
> to the next
> > EventMatch object in the list. Verification of the mock 
> listener also
> > invokes the verificiation on the EventMatch objects.
> > 
> > If this is your idea, can't a similar thing be done with an
> > ExpectationCollection? Initially pushing the expected 
> PropertyChangeEvent
> > objects as expected values and then collecting the actual values?
> 
> Exactly. The only difference is that I would probably write a 
> special EventMatch class, rather than another 
> PropertyChangeEvent, that would let me decide how to specify 
> that it was equal to an incoming Event.

Isn't there just only way to match an expected PropertyChangeEvent with the
actual one? Or would the EventMatch class be the superclass of e.g.
PropertyChangeEventMatch, ListDataEventMatch, etc... wherein the actual
comparison of the expected event type with its actual value happens?

Ringo

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

[Steve F. <sm...@us...>]

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

Modified Files:
	MockPropertyChangeListener.java 
Log Message:
fixed company name

Index: MockPropertyChangeListener.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/beans/MockPropertyChangeListener.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- MockPropertyChangeListener.java	2001/11/14 22:28:50	1.1
+++ MockPropertyChangeListener.java	2001/11/15 22:07:33	1.2
@@ -13,7 +13,7 @@
  * as well as the number of events. If you expect more than one event, only the
  * actual values of the last event are stored.
  *
- * @author Ringo De Smet - <a href="http://www.mediagenix.com">MediaGeniXNV</a>
+ * @author Ringo De Smet - <a href="http://www.mediagenix.com">MediaGeniX NV</a>
  */
 public class MockPropertyChangeListener extends MockObject implements PropertyChangeListener {
 

[MO-java-dev] Re: [Mockobjects-java-dev] [CONTRIB] Mock for PropertyChangeliste ner

[<rin...@me...>]

> I've been looking at this class. Have you actually used it 
> for multiple events? The reason I ask is that the value 
> expectation values can only accept a single value each, 
> although they can receive it multiple times. 

I have used this class for multiple events, but the only thing I verify on
the mock listener at that moment is the number of events received, not the
actual data of each event.

> Depending on your requirements, my inclination would be to 
> define an EventMatch class, that implements equals() on 
> whatever you think is interesting, and set a list of expected 
> EventMatches in the Listener. 

Tell me if my thoughts match yours: the MockPropertyChangeListener maintains
a list of EventMatch objects, in the order I expect each event. When I add
an EventMatch object to the mock listener, the EventMatch object contains a
fully configured PropertyChangeEvent as the expected event. When the
propertyChangeEvent on the mock listener is invoked, it takes the actual
event and pushes it to the EventMatch object, increments the eventCount
expectation. A subsequent call will push the actual event to the next
EventMatch object in the list. Verification of the mock listener also
invokes the verificiation on the EventMatch objects.

If this is your idea, can't a similar thing be done with an
ExpectationCollection? Initially pushing the expected PropertyChangeEvent
objects as expected values and then collecting the actual values?

Ringo

[MO-java-dev] Re: [Mockobjects-java-dev] [CONTRIB] Mock for PropertyChangelistener

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

RnJvbTogPHJpbmdvLmRlc21ldEBtZWRpYWdlbml4LmNvbT4NCj4gSGVyZSBpcyBhIGxpdHRsZSBj
b250cmlidXRpb246IGEgbW9jayBvYmplY3QgZm9yIGEgUHJvcGVydHlDaGFuZ2VMaXN0ZW5lci4N
Cj4gSW4gY29ycmVzcG9uZGVuY2UgdG8gdGhlIGlvIGFuZCBzcWwgc3VicGFja2FnZXMsIEkgcHV0
IHRoaXMgY2xhc3MgaW4gYSBiZWFucw0KPiBzdWJwYWNrYWdlLCBzaW5jZSB0aGUgUHJvcGVydHlD
aGFuZ2VMaXN0ZW5lciBpbnRlcmZhY2UgcmVzaWRlcyBpbg0KPiBqYXZhLmJlYW5zLg0KDQpJJ3Zl
IGJlZW4gbG9va2luZyBhdCB0aGlzIGNsYXNzLiBIYXZlIHlvdSBhY3R1YWxseSB1c2VkIGl0IGZv
ciBtdWx0aXBsZSBldmVudHM/IFRoZSByZWFzb24gSSBhc2sgaXMgdGhhdCB0aGUgdmFsdWUgZXhw
ZWN0YXRpb24gdmFsdWVzIGNhbiBvbmx5IGFjY2VwdCBhIHNpbmdsZSB2YWx1ZSBlYWNoLCBhbHRo
b3VnaCB0aGV5IGNhbiByZWNlaXZlIGl0IG11bHRpcGxlIHRpbWVzLiANCg0KRGVwZW5kaW5nIG9u
IHlvdXIgcmVxdWlyZW1lbnRzLCBteSBpbmNsaW5hdGlvbiB3b3VsZCBiZSB0byBkZWZpbmUgYW4g
RXZlbnRNYXRjaCBjbGFzcywgdGhhdCBpbXBsZW1lbnRzIGVxdWFscygpIG9uIHdoYXRldmVyIHlv
dSB0aGluayBpcyBpbnRlcmVzdGluZywgYW5kIHNldCBhIGxpc3Qgb2YgZXhwZWN0ZWQgRXZlbnRN
YXRjaGVzIGluIHRoZSBMaXN0ZW5lci4gDQoNCkFueXdheSwgSSd2ZSB0aWRpZWQgdXAgYSBmZXcg
dGhpbmdzIHRvIGNvbmZvcm0gdG8gdGhlIHJlc3Qgb2YgdGhlIGxpYnJhcnkgYW5kIGNoZWNrZWQg
aXQgaW4gZm9yIG5vdy4NCg0KU3RldmUNCg0K

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

[Steve F. <sm...@us...>]

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

Added Files:
	MockPropertyChangeListener.java 
Log Message:
New mock object

--- NEW FILE: MockPropertyChangeListener.java ---
package com.mockobjects.beans;

import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import com.mockobjects.ExpectationCounter;
import com.mockobjects.ExpectationValue;
import com.mockobjects.MockObject;

/**
 * Mock object for a PropertyChangeListener.
 * This mock object can be used in verifying the event propagation mechanism
 * of beans. You can set the information you expect from a PropertyChangeEvent
 * as well as the number of events. If you expect more than one event, only the
 * actual values of the last event are stored.
 *
 * @author Ringo De Smet - <a href="http://www.mediagenix.com">MediaGeniXNV</a>
 */
public class MockPropertyChangeListener extends MockObject implements PropertyChangeListener {

    protected ExpectationValue propertyName;
    protected ExpectationValue oldValue;
    protected ExpectationValue newValue;
    protected ExpectationCounter eventCount;

    public MockPropertyChangeListener(String name) {
        propertyName = new ExpectationValue(name + ".propertyName");
        oldValue = new ExpectationValue(name + ".oldValue");
        newValue = new ExpectationValue(name + ".newValue");
        eventCount = new ExpectationCounter(name +  ".expectedNrOfEvents");
    }

    public MockPropertyChangeListener() {
        this("MockPropertyChangeListener");
    }

    public void propertyChange(PropertyChangeEvent event) {
        propertyName.setActual(event.getPropertyName());
        oldValue.setActual(event.getOldValue());
        newValue.setActual(event.getNewValue());
        eventCount.inc();
    }

    public void setExpectedNewValue(Object expectedNewValue) {
        newValue.setExpected(expectedNewValue);
    }

    public void setExpectedOldValue(Object expectedOldValue) {
        oldValue.setExpected(expectedOldValue);
    }

    public void setExpectedEventCount(int expectedEventCount) {
        eventCount.setExpected(expectedEventCount);
    }

    public void setExpectedPropertyName(String expectedPropertyName) {
        propertyName.setExpected(expectedPropertyName);
    }

}

[MO-java-dev] CVS: mockobjects-java/src/core/com/mockobjects/beans - New directory

[Steve F. <sm...@us...>]

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

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/src/core/com/mockobjects/beans added to the repository

Re: [MO-java-dev] Re: [Mockobjects-java-dev] servlets library

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

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, November 14, 2001 12:25 AM
Subject: [MO-java-dev] Re: [Mockobjects-java-dev] servlets library


> If one version would do, I would be happier.
>

That would mean that servlet 2.1 users will see all setupXXX, setExpectedXXX
for servlet api 2.2 and 2.3. Same, servlet api 2.3 users (for example) will
see setupXXX and setExpectedXXX for methods that do *not* exist anymore
[because deprecation works only for such an amount of time and then method
is removed - not sure if any has been removed yet but if not it'll come soon
enough].

I would also prefer a single version but not sure it is doable for the above
reasons. That's a general question that will happen for all our mocks. The
problem already exists for api that have changed in the jdk between 1.4 and
1.1. We need to find a mechanism ... I have no good solution for now to
propose ... :)

-Vincent

> Steve
>
> ----- Original Message -----
> From: "Jeff Martin" <je...@mk...>
> To: <moc...@li...>
> Sent: Tuesday, November 13, 2001 3:02 PM
> Subject: Re: [Mockobjects-java-dev] servlets library
>
>
> > I've actually got some mock objects written against the 2.3 api, there
> > not complete but they do add support for things like Filters
> >
> > As far as I can tell the 2.3 api is backwards compatible with the 2.1
> > version (think it's actually a requirement of the spec) so you don't
> > need to versions. Although there could be reasons for it on grounds of
> > causing less confusion although it is more work.
>
>
>
2?$¡¸ÞrÛ#jözùsSX§,X¬´Ê'?ãyËl«ÚuëåSËl²<«qç讧zØm¶>?þX¬¶Ë(º·~Sàzw­þX¬¶ÏåS
Ëbú?s?$¡¸ÞrÛ#jö

Re: [MO-java-dev] Re: [Mockobjects-java-dev] build organisation

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

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, November 14, 2001 12:24 AM
Subject: [MO-java-dev] Re: [Mockobjects-java-dev] build organisation


> From: "Vincent Massol" <vm...@oc...>
> > If I remember correctly that's what I proposed some time ago so I am
more
>
> yes, but we didn't need it then. Now we do ;-)

that's where knowledge may be stronger than XP ... ;-)

[XP says YAGNI. Knowledge says : with my great experience I know that we'll
need it for sure soon enough ...]

>
> > than happy with that :-). I would even go as far as :
>
>
> 2?¡¸rÛjözùSX,X´Ê'?yˍ«uëS˲þX¶Ëº·~SzwþX¶ÏS˝ús?¡¸rÛjö

RE: [MO-java-dev] Re: [Mockobjects-java-dev] build organisation

[<rin...@me...>]

> > Core - If you want to use the mock JUnit extension
> > j2se - Mock objects if you have the standard JDK
> > j2ee - Mock objects if you have the enterprise JDK
> 
> do you agree with Vincent that we should deliver multiple 
> jars? I'm still wondering about delivering everything up to 
> j2ee in the shipped jar and allowing people to control what 
> gets included when they build locally using Vincent's ant trick. 

Hmm... OK, one jar for Core & J2SE, but I would prefer an additional jar for
the J2EE part. Please don't ask all the users to build a JAR of what they
need. I would prefer to have you build *official* JAR files that make up the
MockObjects thing when you do a release.

Ringo

[MO-java-dev] Re: [Mockobjects-java-dev] When a new version?

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

V2UndmUgYmVlbiBnZXR0aW5nIGtpbmRhIGxhenkgYW5kIGp1c3QgY2hlY2tpbmcgc3R1ZmYgaW4g
dG8gQ1ZTLiANCg0KSXQncyBhYm91dCB0aW1lIHRvIGNyZWF0ZSBhIG5ldyBkcm9wLg0KDQpTdGV2
ZQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPHJpbmdvLmRlc21ldEBt
ZWRpYWdlbml4LmNvbT4NClRvOiA8bW9ja29iamVjdHMtamF2YS1kZXZAbGlzdHMuc291cmNlZm9y
Z2UubmV0Pg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTMsIDIwMDEgODoyNyBBTQ0KU3ViamVj
dDogW01vY2tvYmplY3RzLWphdmEtZGV2XSBXaGVuIGEgbmV3IHZlcnNpb24/DQoNCg0KPiBIZWxs
byBndXlzLA0KPiANCj4gSSBsb29rZWQgb24gdGhlIGZpbGVzIHNlY3Rpb24gb2YgdGhlIFNGIHBh
Z2UgYW5kIGl0IG1lbnRpb25zIHRoYXQgdGhlIDAuMDENCj4gYnVpbGQgaXMgZnJvbSBBdWd1c3Qg
MTIsIGFuZCB0aGUgbGF0ZXN0IGRldmVsb3BtZW50IGJ1aWxkIGlzIGV2ZW4gb2xkZXIuIENhbg0K
PiBvbmUgb2YgeW91IHRlbGwgbWUgd2hlbiBJIGNhbiBleHBlY3QgYSBuZXcgb2ZmaWNpYWwgdmVy
c2lvbiAoMC4wMj8pID8NCj4gDQo+IFJpbmdvDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBNb2Nrb2JqZWN0cy1qYXZhLWRldiBtYWlsaW5n
IGxpc3QNCj4gTW9ja29iamVjdHMtamF2YS1kZXZAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IGh0
dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL21vY2tvYmplY3RzLWph
dmEtZGV2DQo+IA0K

[MO-java-dev] Re: [Mockobjects-java-dev] MockConnection question

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

VHJ5IA0KDQogIGFkZEV4cGVjdGVkUHJlcGFyZWRTdGF0ZW1lbnRTdHJpbmcoKQ0KDQpNb2NrQ29u
bmVjdGlvbiBzdXBwb3J0cyBtdWx0aXBsZSBwcmVwYXJlZCBzdGF0ZW1lbnRzDQoNClN0ZXZlDQoN
Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVmluY2VudCBNYXNzb2wiIDx2
bWFzc29sQG9jdG8uY29tPg0KVG86IDxtb2Nrb2JqZWN0cy1qYXZhLWRldkBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQ+DQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMywgMjAwMSAxMToyMCBQTQ0KU3Vi
amVjdDogW01vY2tvYmplY3RzLWphdmEtZGV2XSBNb2NrQ29ubmVjdGlvbiBxdWVzdGlvbg0KDQoN
Cj4gU3RldmUsDQo+IA0KPiBXaHkgaXNuJ3QgdGhlcmUgYSBNb2NrQ29ubmVjdGlvbi5zZXRFeHBl
Y3RlZFByZXBhcmVTdGF0ZW1lbnRTdHJpbmcoKSBpbg0KPiBjb20ubW9ja29iamVjdHMuc3FsLk1v
Y2tDb25uZWN0aW9uIChhcyBpbiB5b3VyIGpkYmMgdGVzdCBmaXJzdCBwYXBlcikgPw0KPiANCj4g
SSB0aGluayBpdCB3b3VsZCBiZSBuZWVkZWQ7IG90aGVyd2lzZSwgSSBoYXZlIG5vIHdheSBvZiBj
aGVja2luZyB0aGUgY29ycmVjdA0KPiBxdWVyeSBzdHJpbmcgaXMgY29ycmVjdGx5IHBhc3NlZCB0
byB0aGUgc3RhdGVtZW50Lg0KPiANCj4gTXkgdGVzdCBjb2RlIDoNCj4gDQo+ICAgICAgICAgc3Rh
dGVtZW50LnNldEV4cGVjdGVkUXVlcnlTdHJpbmcoInNvbWUgU1FMIHF1ZXJ5Iik7DQo+ICAgICAg
ICAgc3RhdGVtZW50LnNldEV4cGVjdGVkRXhlY3V0ZUNhbGxzKDEpOw0KPiAgICAgICAgIHN0YXRl
bWVudC5zZXRFeHBlY3RpbmdOb1NldFBhcmFtZXRlcnMoKTsNCj4gDQo+IE15IGNvZGUgdW5kZXIg
dGVzdCA6DQo+IA0KPiAgICAgICAgIFByZXBhcmVkU3RhdGVtZW50IHN0YXRlbWVudCA9DQo+IHRo
aXMuY29ubmVjdGlvbi5wcmVwYXJlU3RhdGVtZW50KHF1ZXJ5KTsNCj4gICAgICAgICBSZXN1bHRT
ZXQgcnMgPSBzdGF0ZW1lbnQuZXhlY3V0ZVF1ZXJ5KCk7DQo+IA0KPiBUaGFua3MNCj4gLVZpbmNl
bnQNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiBNb2Nrb2JqZWN0cy1qYXZhLWRldiBtYWlsaW5nIGxpc3QNCj4gTW9ja29iamVjdHMt
amF2YS1kZXZAbGlzdHMuc291cmNlZm9yZ2UubmV0DQo+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9y
Z2UubmV0L2xpc3RzL2xpc3RpbmZvL21vY2tvYmplY3RzLWphdmEtZGV2DQo+IA0KDQo=

[MO-java-dev] Re: [Mockobjects-java-dev] build organisation

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

DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPHJpbmdvLmRlc21ldEBtZWRp
YWdlbml4LmNvbT4NCj4gSSBmdWxseSBhZ3JlZS4gSSBzb21ldGltZXMgaGF2ZSBhIGZpZ2h0IGhl
cmUgaW4gdGhlIG9mZmljZSB3aXRoIHBlb3BsZSB0aGF0DQo+IHdhbnQgdG8gcHV0IGV2ZXJ5dGhp
bmcgaW4gb25lIGphciB3aXRob3V0IHRoaW5raW5nIGFib3V0IGRlcGVuZGVuY2llcy4gWW91cg0K
PiBwcm9wb3NlZCBzcGxpdC11cCBjbGVhcmx5IGlkZW50aWZpZXMgdGhpcyBkZXBlbmRlbmNpZXMu
DQo+IA0KPiBDb3JlIC0gSWYgeW91IHdhbnQgdG8gdXNlIHRoZSBtb2NrIEpVbml0IGV4dGVuc2lv
bg0KPiBqMnNlIC0gTW9jayBvYmplY3RzIGlmIHlvdSBoYXZlIHRoZSBzdGFuZGFyZCBKREsNCj4g
ajJlZSAtIE1vY2sgb2JqZWN0cyBpZiB5b3UgaGF2ZSB0aGUgZW50ZXJwcmlzZSBKREsNCg0KZG8g
eW91IGFncmVlIHdpdGggVmluY2VudCB0aGF0IHdlIHNob3VsZCBkZWxpdmVyIG11bHRpcGxlIGph
cnM/IEknbSBzdGlsbCB3b25kZXJpbmcgYWJvdXQgZGVsaXZlcmluZyBldmVyeXRoaW5nIHVwIHRv
IGoyZWUgaW4gdGhlIHNoaXBwZWQgamFyIGFuZCBhbGxvd2luZyBwZW9wbGUgdG8gY29udHJvbCB3
aGF0IGdldHMgaW5jbHVkZWQgd2hlbiB0aGV5IGJ1aWxkIGxvY2FsbHkgdXNpbmcgVmluY2VudCdz
IGFudCB0cmljay4gDQoNClN0ZXZlDQoNCg==

[MO-java-dev] Re: [Mockobjects-java-dev] build organisation

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

RnJvbTogIlZpbmNlbnQgTWFzc29sIiA8dm1hc3NvbEBvY3RvLmNvbT4NCj4gSWYgSSByZW1lbWJl
ciBjb3JyZWN0bHkgdGhhdCdzIHdoYXQgSSBwcm9wb3NlZCBzb21lIHRpbWUgYWdvIHNvIEkgYW0g
bW9yZQ0KDQp5ZXMsIGJ1dCB3ZSBkaWRuJ3QgbmVlZCBpdCB0aGVuLiBOb3cgd2UgZG8gOy0pDQoN
Cj4gdGhhbiBoYXBweSB3aXRoIHRoYXQgOi0pLiBJIHdvdWxkIGV2ZW4gZ28gYXMgZmFyIGFzIDoN
Cg0KDQo=

[MO-java-dev] Re: [Mockobjects-java-dev] servlets library

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

SWYgb25lIHZlcnNpb24gd291bGQgZG8sIEkgd291bGQgYmUgaGFwcGllci4NCg0KU3RldmUNCg0K
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKZWZmIE1hcnRpbiIgPGplZmZA
bWtvZG8uY29tPg0KVG86IDxtb2Nrb2JqZWN0cy1qYXZhLWRldkBsaXN0cy5zb3VyY2Vmb3JnZS5u
ZXQ+DQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMywgMjAwMSAzOjAyIFBNDQpTdWJqZWN0OiBS
ZTogW01vY2tvYmplY3RzLWphdmEtZGV2XSBzZXJ2bGV0cyBsaWJyYXJ5DQoNCg0KPiBJJ3ZlIGFj
dHVhbGx5IGdvdCBzb21lIG1vY2sgb2JqZWN0cyB3cml0dGVuIGFnYWluc3QgdGhlIDIuMyBhcGks
IHRoZXJlDQo+IG5vdCBjb21wbGV0ZSBidXQgdGhleSBkbyBhZGQgc3VwcG9ydCBmb3IgdGhpbmdz
IGxpa2UgRmlsdGVycw0KPiANCj4gQXMgZmFyIGFzIEkgY2FuIHRlbGwgdGhlIDIuMyBhcGkgaXMg
YmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCB0aGUgMi4xDQo+IHZlcnNpb24gKHRoaW5rIGl0J3Mg
YWN0dWFsbHkgYSByZXF1aXJlbWVudCBvZiB0aGUgc3BlYykgc28geW91IGRvbid0DQo+IG5lZWQg
dG8gdmVyc2lvbnMuIEFsdGhvdWdoIHRoZXJlIGNvdWxkIGJlIHJlYXNvbnMgZm9yIGl0IG9uIGdy
b3VuZHMgb2YNCj4gY2F1c2luZyBsZXNzIGNvbmZ1c2lvbiBhbHRob3VnaCBpdCBpcyBtb3JlIHdv
cmsuDQoNCg0K

[Mockobjects-java-dev] MockConnection question

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

Steve,

Why isn't there a MockConnection.setExpectedPrepareStatementString() in
com.mockobjects.sql.MockConnection (as in your jdbc test first paper) ?

I think it would be needed; otherwise, I have no way of checking the correct
query string is correctly passed to the statement.

My test code :

        statement.setExpectedQueryString("some SQL query");
        statement.setExpectedExecuteCalls(1);
        statement.setExpectingNoSetParameters();

My code under test :

        PreparedStatement statement =
this.connection.prepareStatement(query);
        ResultSet rs = statement.executeQuery();

Thanks
-Vincent

Re: [Mockobjects-java-dev] servlets library

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

I've actually got some mock objects written against the 2.3 api, there
not complete but they do add support for things like Filters

As far as I can tell the 2.3 api is backwards compatible with the 2.1
version (think it's actually a requirement of the spec) so you don't
need to versions. Although there could be reasons for it on grounds of
causing less confusion although it is more work.

On Mon, 2001-11-12 at 22:36, Vincent Massol wrote:
> Do you mean that the mocks are not complete or that the mocked api is 2.1=
 ?
> (I'm not sure about the version but that's my guess seen that you guys we=
re
> using vajava when you wrote it ... :) ).
>=20
> I think we should have at least 2 packages : one for servlet api 2.2 and =
one
> for servlet api 2.3.
>=20
> you doing it Steve ... :-)
>=20
> Thanks
> -Vincent
>=20
> ----- Original Message -----
> From: "Steve Freeman" <st...@m3...>
> To: <moc...@li...>
> Sent: Monday, November 12, 2001 10:18 PM
> Subject: [Mockobjects-java-dev] servlets library
>=20
>=20
> > I think the current implementation of servlets is a bit out of date.
> Anyone object to bringing it up to date?
> >
> > I think the new stuff is largely additive, so there shouldn't be a
> backwards compatibility issue.
> >
> > Steve
> >
> > 2=A1rjzS,=B4'y=8DuS=B2q=AEz=B6=FE=B6=BA~z=FE=B6S=9Ds=A1rj
>=20
>=20
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
--=20