Menu
▾
▴
mockobjects-java-dev
|
From: Christian T. <ch...@sm...> - 2002-04-15 17:37:53
|
Hi mockobjects community,
in one of my projects I use java.sql.ResutSetMetaData. Because I test-first
my java classes ;-) and it dosn't exists a suck mock object I write a very
rudimentary mock resultset meta data ...
It works, and I think this is a usefull class for the com.mockobjects.sql
package ...
Chris
--- CODE SNIPLET ---
package com.mockobjects.sql;
import com.mockobjects.*;
import java.sql.*;
import java.sql.SQLException;
public class MockResultSetMetaData
extends MockObject
implements ResultSetMetaData {
private String[] names = null;
private Object[] values = null;
public MockResultSetMetaData(String[] names, Object[] values) {
super();
this.names = names;
this.values = values;
}
/**
* @see ResultSetMetaData#getColumnCount()
*/
public int getColumnCount() throws SQLException {
return names.length;
}
/**
* @see ResultSetMetaData#isAutoIncrement(int)
*/
public boolean isAutoIncrement(int arg0) throws SQLException {
return false;
}
/**
* @see ResultSetMetaData#isCaseSensitive(int)
*/
public boolean isCaseSensitive(int arg0) throws SQLException {
return false;
}
/**
* @see ResultSetMetaData#isSearchable(int)
*/
public boolean isSearchable(int arg0) throws SQLException {
return false;
}
/**
* @see ResultSetMetaData#isCurrency(int)
*/
public boolean isCurrency(int arg0) throws SQLException {
return false;
}
/**
* @see ResultSetMetaData#isNullable(int)
*/
public int isNullable(int arg0) throws SQLException {
return 0;
}
/**
* @see ResultSetMetaData#isSigned(int)
*/
public boolean isSigned(int arg0) throws SQLException {
return false;
}
/**
* @see ResultSetMetaData#getColumnDisplaySize(int)
*/
public int getColumnDisplaySize(int arg0) throws SQLException {
return 0;
}
/**
* @see ResultSetMetaData#getColumnLabel(int)
*/
public String getColumnLabel(int arg0) throws SQLException {
return null;
}
/**
* @see ResultSetMetaData#getColumnName(int)
*/
public String getColumnName(int arg0) throws SQLException {
return names[arg0 - 1];
}
/**
* @see ResultSetMetaData#getSchemaName(int)
*/
public String getSchemaName(int arg0) throws SQLException {
return null;
}
/**
* @see ResultSetMetaData#getPrecision(int)
*/
public int getPrecision(int arg0) throws SQLException {
return 0;
}
/**
* @see ResultSetMetaData#getScale(int)
*/
public int getScale(int arg0) throws SQLException {
return 0;
}
/**
* @see ResultSetMetaData#getTableName(int)
*/
public String getTableName(int arg0) throws SQLException {
return null;
}
/**
* @see ResultSetMetaData#getCatalogName(int)
*/
public String getCatalogName(int arg0) throws SQLException {
return null;
}
/**
* @see ResultSetMetaData#getColumnType(int)
*/
public int getColumnType(int arg0) throws SQLException {
return 0;
}
/**
* @see ResultSetMetaData#getColumnTypeName(int)
*/
public String getColumnTypeName(int arg0) throws SQLException {
return null;
}
/**
* @see ResultSetMetaData#isReadOnly(int)
*/
public boolean isReadOnly(int arg0) throws SQLException {
return false;
}
/**
* @see ResultSetMetaData#isWritable(int)
*/
public boolean isWritable(int arg0) throws SQLException {
return false;
}
/**
* @see ResultSetMetaData#isDefinitelyWritable(int)
*/
public boolean isDefinitelyWritable(int arg0) throws SQLException {
return false;
}
/**
* @see ResultSetMetaData#getColumnClassName(int)
*/
public String getColumnClassName(int arg0) throws SQLException {
return null;
}
}
|
|
From: Christian T. <ch...@sm...> - 2002-04-16 15:44:42
|
Hi Jeff,
I think the changes in MockResultSetMetaData are OK, I use now your
MockResultSetMetaData ...
The method:
public void addColumnNames(String[] allNames) {
if (allNames != null) {
for (int i = 0; i < allNames.length; i++) {
addColumnName(allNames[i]);
}
}
}
is also usefull because you can create a String[] with column names and
transfer it to MockResultSet and MockResultSetMetaData. We should use common
parameter types for this classes ...
Christian
|
|
From: Steve F. <st...@m3...> - 2002-04-17 21:27:26
|
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 |
|
From: Oskar H. <osk...@de...> - 2002-04-18 08:36:57
|
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 |
|
From: Jeff M. <je...@mk...> - 2002-04-16 13:50:38
|
I've made a couple of changes to your code and applied it to the main
tree.
Instead of passing in the mock data in the constructor, I've added a
method addColumnName(String aColumnName)
I've also added calls to notImplemented in those methods without a full
implementation.
Ta
On Mon, 2002-04-15 at 18:39, Christian Trutz wrote:
> Hi mockobjects community,
>
> in one of my projects I use java.sql.ResutSetMetaData. Because I test-first
> my java classes ;-) and it dosn't exists a suck mock object I write a very
> rudimentary mock resultset meta data ...
>
> It works, and I think this is a usefull class for the com.mockobjects.sql
> package ...
>
>
> Chris
>
> --- CODE SNIPLET ---
>
>
> package com.mockobjects.sql;
> import com.mockobjects.*;
> import java.sql.*;
> import java.sql.SQLException;
>
> public class MockResultSetMetaData
> extends MockObject
> implements ResultSetMetaData {
> private String[] names = null;
> private Object[] values = null;
> public MockResultSetMetaData(String[] names, Object[] values) {
> super();
> this.names = names;
> this.values = values;
> }
> /**
> * @see ResultSetMetaData#getColumnCount()
> */
> public int getColumnCount() throws SQLException {
> return names.length;
> }
> /**
> * @see ResultSetMetaData#isAutoIncrement(int)
> */
> public boolean isAutoIncrement(int arg0) throws SQLException {
> return false;
> }
> /**
> * @see ResultSetMetaData#isCaseSensitive(int)
> */
> public boolean isCaseSensitive(int arg0) throws SQLException {
> return false;
> }
> /**
> * @see ResultSetMetaData#isSearchable(int)
> */
> public boolean isSearchable(int arg0) throws SQLException {
> return false;
> }
> /**
> * @see ResultSetMetaData#isCurrency(int)
> */
> public boolean isCurrency(int arg0) throws SQLException {
> return false;
> }
> /**
> * @see ResultSetMetaData#isNullable(int)
> */
> public int isNullable(int arg0) throws SQLException {
> return 0;
> }
> /**
> * @see ResultSetMetaData#isSigned(int)
> */
> public boolean isSigned(int arg0) throws SQLException {
> return false;
> }
> /**
> * @see ResultSetMetaData#getColumnDisplaySize(int)
> */
> public int getColumnDisplaySize(int arg0) throws SQLException {
> return 0;
> }
> /**
> * @see ResultSetMetaData#getColumnLabel(int)
> */
> public String getColumnLabel(int arg0) throws SQLException {
> return null;
> }
> /**
> * @see ResultSetMetaData#getColumnName(int)
> */
> public String getColumnName(int arg0) throws SQLException {
> return names[arg0 - 1];
> }
> /**
> * @see ResultSetMetaData#getSchemaName(int)
> */
> public String getSchemaName(int arg0) throws SQLException {
> return null;
> }
> /**
> * @see ResultSetMetaData#getPrecision(int)
> */
> public int getPrecision(int arg0) throws SQLException {
> return 0;
> }
> /**
> * @see ResultSetMetaData#getScale(int)
> */
> public int getScale(int arg0) throws SQLException {
> return 0;
> }
> /**
> * @see ResultSetMetaData#getTableName(int)
> */
> public String getTableName(int arg0) throws SQLException {
> return null;
> }
> /**
> * @see ResultSetMetaData#getCatalogName(int)
> */
> public String getCatalogName(int arg0) throws SQLException {
> return null;
> }
> /**
> * @see ResultSetMetaData#getColumnType(int)
> */
> public int getColumnType(int arg0) throws SQLException {
> return 0;
> }
> /**
> * @see ResultSetMetaData#getColumnTypeName(int)
> */
> public String getColumnTypeName(int arg0) throws SQLException {
> return null;
> }
> /**
> * @see ResultSetMetaData#isReadOnly(int)
> */
> public boolean isReadOnly(int arg0) throws SQLException {
> return false;
> }
> /**
> * @see ResultSetMetaData#isWritable(int)
> */
> public boolean isWritable(int arg0) throws SQLException {
> return false;
> }
> /**
> * @see ResultSetMetaData#isDefinitelyWritable(int)
> */
> public boolean isDefinitelyWritable(int arg0) throws SQLException {
> return false;
> }
> /**
> * @see ResultSetMetaData#getColumnClassName(int)
> */
> public String getColumnClassName(int arg0) throws SQLException {
> return null;
> }
> }
>
>
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
--
|
|
From: Oskar H. <osk...@de...> - 2002-04-16 16:35:19
|
Hi there! It is nice to see the MockResultSetMetaData class finally make its way in to CVS , even though I posted similar code (+ unit test) some six months ago:-( When I started using Mockobjects last year I ran in to problems having multiple Statements pr. connection. The current version of MockConnection supports only one Statement pr. connection so I modified it and posted it to this group. The code never made it to the CVS so I ask: Is someone currently working on this problem or should I try to re-commit my implementation and hope for a better response ? I found some 8 months old code in CVS (mockobjects-java/src/extensions/com/mockobjects/eziba/sql) which seem to be addressing some this problem. Is this perhaps an upcoming version of the sql package? Regards Oskar Hannesson deCODE Genetics Addr: Sturlugata 8 , 101 Reykjavik, Iceland Tel: (354) 570-1900 Fax: (354) 570-1903 Web: www.decode.com PS! I really hate relying on my own private version of MockObjects. |
|
From: Christian T. <ch...@sm...> - 2002-04-16 16:56:50
|
Hi Oskar, some unit tests for MockResultSetMetaData would be very nice ;-) Christian -----Ursprüngliche Nachricht----- Von: moc...@li... [mailto:moc...@li...]Im Auftrag von Oskar Hannesson Gesendet: Dienstag, 16. April 2002 18:34 An: 'Jeff Martin'; 'MockObjects' Betreff: [MO-java-dev] MockConnection Hi there! It is nice to see the MockResultSetMetaData class finally make its way in to CVS , even though I posted similar code (+ unit test) some six months ago:-( When I started using Mockobjects last year I ran in to problems having multiple Statements pr. connection. The current version of MockConnection supports only one Statement pr. connection so I modified it and posted it to this group. The code never made it to the CVS so I ask: Is someone currently working on this problem or should I try to re-commit my implementation and hope for a better response ? I found some 8 months old code in CVS (mockobjects-java/src/extensions/com/mockobjects/eziba/sql) which seem to be addressing some this problem. Is this perhaps an upcoming version of the sql package? Regards Oskar Hannesson deCODE Genetics Addr: Sturlugata 8 , 101 Reykjavik, Iceland Tel: (354) 570-1900 Fax: (354) 570-1903 Web: www.decode.com PS! I really hate relying on my own private version of MockObjects. _______________________________________________ Mockobjects-java-dev mailing list Moc...@li... https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev |
|
From: Jeff M. <je...@mk...> - 2002-04-16 17:14:30
|
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. On Tue, 2002-04-16 at 17:58, Christian Trutz wrote: > Hi Oskar, >=20 > some unit tests for MockResultSetMetaData would be very nice ;-) >=20 > Christian >=20 > -----Urspr=FCngliche Nachricht----- > Von: moc...@li... > [mailto:moc...@li...]Im Auftrag von > Oskar Hannesson > Gesendet: Dienstag, 16. April 2002 18:34 > An: 'Jeff Martin'; 'MockObjects' > Betreff: [MO-java-dev] MockConnection >=20 >=20 > Hi there! > It is nice to see the MockResultSetMetaData class finally make its way in= to > CVS , even though I posted similar code (+ unit test) some six months ago= :-( > When I started using Mockobjects last year I ran in to problems having > multiple Statements pr. connection. > The current version of MockConnection supports only one Statement pr. > connection so I modified it and posted it to this group. > The code never made it to the CVS so I ask: > Is someone currently working on this problem or should I try to re-commit= my > implementation and hope for a better response ? >=20 > I found some 8 months old code in CVS > (mockobjects-java/src/extensions/com/mockobjects/eziba/sql) which seem to= be > addressing some this problem. > Is this perhaps an upcoming version of the sql package? >=20 > Regards > Oskar Hannesson > deCODE Genetics > Addr: Sturlugata 8 , 101 Reykjavik, Iceland > Tel: (354) 570-1900 > Fax: (354) 570-1903 > Web: www.decode.com >=20 > PS! > I really hate relying on my own private version of MockObjects. >=20 >=20 > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev >=20 >=20 >=20 > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev --=20 |
|
From: Steve F. <st...@m3...> - 2002-04-17 21:58:07
|
> 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. |
|
From: Jeff M. <je...@mk...> - 2002-04-18 16:13:31
|
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. |
|
From: Oskar H. <osk...@de...> - 2002-04-17 10:20:54
Attachments:
MockResultSetMetaData.java
TestMockResultSetMetaData.java
|
Hi.
I could not live with out the unit tests ... they make you feel so safe :)
I ran my modified Unit test against your code and found three things
missing.
* Missing set-up method for getTableName()
* Missing set-up method for getColumnClassName()
* The getColumnLabel(...) should return the same value as
getColumName(...) (At least my Oracle JDBC drivers does so)
Also I saw that you used myNames.remove(0) when you retrieve the column
Name.
Shouldn't it be implemented like this :
public String getColumnName(int aColumnIndex) throws SQLException {
return (String)myNames.get(aColumnIndex-1);
}
In stead of:
public String getColumnName(int aColumnIndex) throws SQLException {
return (String)myNames.remove(0);
}
Anyway I applied the above changes to MockResultSetMetaData and attached it
to this mail plus the Unit test.
I put the unittest under the package "com.mockobjects.sql.test"
Regards.
Oskar H.
PS! Here is a diff -u of the code
---
C:\tmp\mockobjects\mockobjects-java\src\jdk\common\com\mockobjects\sql\MockR
esultSetMetaData.java Tue Apr 16 17:04:02 2002
+++
C:\projects\MockObjects2\src\jdk\common\com\mockobjects\sql\MockResultSetMet
aData.java Wed Apr 17 09:38:49 2002
@@ -9,6 +9,8 @@
implements ResultSetMetaData {
private Vector myNames =3D new Vector();
+ private Vector myTableNames =3D new Vector();
+ private Vector myColumnClassNames =3D new Vector();
/**
* @see ResultSetMetaData#getColumnCount()
@@ -76,9 +78,8 @@
/**
* @see ResultSetMetaData#getColumnLabel(int)
*/
- public String getColumnLabel(int arg0) throws SQLException {
- notImplemented();
- return null;
+ public String getColumnLabel(int aColumnIndex) throws SQLException {
+ return getColumnName(aColumnIndex);
}
public void addColumnNames(String[] allNames) {
@@ -97,7 +98,7 @@
* @see ResultSetMetaData#getColumnName(int)
*/
public String getColumnName(int aColumnIndex) throws SQLException {
- return (String)myNames.remove(0);
+ return (String)myNames.get(aColumnIndex-1);
}
/**
@@ -127,9 +128,16 @@
/**
* @see ResultSetMetaData#getTableName(int)
*/
- public String getTableName(int arg0) throws SQLException {
- notImplemented();
- return null;
+ public String getTableName(int aColumnIndex) throws SQLException {
+ return (String)myTableNames.get(aColumnIndex-1);
+ }
+
+ public void addTableNames(String[] allNames) {
+ if (myTableNames !=3D null) {
+ for (int i =3D 0; i < allNames.length; i++) {
+ myTableNames.add(allNames[i]);
+ }
+ }
}
/**
@@ -183,8 +191,15 @@
/**
* @see ResultSetMetaData#getColumnClassName(int)
*/
- public String getColumnClassName(int arg0) throws SQLException {
- notImplemented();
- return null;
+ public String getColumnClassName(int aColumnIndex) throws SQLException
{
+ return (String)myColumnClassNames.get(aColumnIndex-1);
+ }
+
+ public void addColumnClassNames(String[] allNames) {
+ if (myColumnClassNames !=3D null) {
+ for (int i =3D 0; i < allNames.length; i++) {
+ myColumnClassNames.add(allNames[i]);
+ }
+ }
}
}
------------------- THE DIFF END ----------------------------
-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Christian Trutz
Sent: 16. apr=EDl 2002 16:58
To: Mockobjects
Subject: Re: [MO-java-dev] MockConnection
Hi Oskar,
some unit tests for MockResultSetMetaData would be very nice ;-)
Christian
-----Urspr=FCngliche Nachricht-----
Von: moc...@li...
[mailto:moc...@li...]Im Auftrag von
Oskar Hannesson
Gesendet: Dienstag, 16. April 2002 18:34
An: 'Jeff Martin'; 'MockObjects'
Betreff: [MO-java-dev] MockConnection
Hi there!
It is nice to see the MockResultSetMetaData class finally make its way in to
CVS , even though I posted similar code (+ unit test) some six months ago:-(
When I started using Mockobjects last year I ran in to problems having
multiple Statements pr. connection.
The current version of MockConnection supports only one Statement pr.
connection so I modified it and posted it to this group.
The code never made it to the CVS so I ask:
Is someone currently working on this problem or should I try to re-commit my
implementation and hope for a better response ?
I found some 8 months old code in CVS
(mockobjects-java/src/extensions/com/mockobjects/eziba/sql) which seem to be
addressing some this problem.
Is this perhaps an upcoming version of the sql package?
Regards
Oskar Hannesson
deCODE Genetics
Addr: Sturlugata 8 , 101 Reykjavik, Iceland
Tel: (354) 570-1900
Fax: (354) 570-1903
Web: www.decode.com
PS!
I really hate relying on my own private version of MockObjects.
=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
=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
|
|
From: Jeff M. <je...@mk...> - 2002-04-17 11:51:05
|
On Wed, 2002-04-17 at 11:19, Oskar Hannesson wrote:
> Hi.
> I could not live with out the unit tests ... they make you feel so safe :=
)
>=20
> I ran my modified Unit test against your code and found three things
> missing.
> * Missing set-up method for getTableName()
> * Missing set-up method for getColumnClassName()
> * The getColumnLabel(...) should return the same value as
> getColumName(...) (At least my Oracle JDBC drivers does so)
>=20
> Also I saw that you used myNames.remove(0) when you retrieve the column
> Name.
> Shouldn't it be implemented like this :
> public String getColumnName(int aColumnIndex) throws SQLException {
> return (String)myNames.get(aColumnIndex-1);
> }
> In stead of:
> public String getColumnName(int aColumnIndex) throws SQLException {
> return (String)myNames.remove(0);
> }
The idea behind this this is to setup a list of the columns that are
needed in the order they are required. So regardless of the number
that's passed in you get the column name out that you setup in the test.
What we should also have is a list of the expected indexes.
private ExpectationList myColumnIndices =3D new
ExpectationList("ColumnIndices");
...
public void addExpectedColumnIndices(int aColumnIndex) throws SQLException =
{
myColumnIndices.addExpected(aColumnIndex);
}
public String getColumnName(int aColumnIndex) throws SQLException {
myColumnIndices.addActual(aColumnIndex);
return (String)myNames.remove(0);
}
This way you separating out the two things your testing.
1. That your requesting the right columns in the right order=20
e.g 1,2,3,4 not 1,1,1,1,3,4
2. That the code that handles the column name behaves correctly given a
know list of columns names.
I'll put you path in with the above changes unless anyone yells at me
first ;o)
>=20
> Anyway I applied the above changes to MockResultSetMetaData and attached =
it
> to this mail plus the Unit test.
> I put the unittest under the package "com.mockobjects.sql.test"
>=20
> Regards.
> Oskar H.
>=20
> PS! Here is a diff -u of the code
>=20
> ---
> C:\tmp\mockobjects\mockobjects-java\src\jdk\common\com\mockobjects\sql\Mo=
ckR
> esultSetMetaData.java Tue Apr 16 17:04:02 2002
> +++
> C:\projects\MockObjects2\src\jdk\common\com\mockobjects\sql\MockResultSet=
Met
> aData.java Wed Apr 17 09:38:49 2002
> @@ -9,6 +9,8 @@
> implements ResultSetMetaData {
>=20
> private Vector myNames =3D new Vector();
> + private Vector myTableNames =3D new Vector();
> + private Vector myColumnClassNames =3D new Vector();
>=20
> /**
> * @see ResultSetMetaData#getColumnCount()
> @@ -76,9 +78,8 @@
> /**
> * @see ResultSetMetaData#getColumnLabel(int)
> */
> - public String getColumnLabel(int arg0) throws SQLException {
> - notImplemented();
> - return null;
> + public String getColumnLabel(int aColumnIndex) throws SQLException {
> + return getColumnName(aColumnIndex);
> }
>=20
> public void addColumnNames(String[] allNames) {
> @@ -97,7 +98,7 @@
> * @see ResultSetMetaData#getColumnName(int)
> */
> public String getColumnName(int aColumnIndex) throws SQLException {
> - return (String)myNames.remove(0);
> + return (String)myNames.get(aColumnIndex-1);
> }
>=20
> /**
> @@ -127,9 +128,16 @@
> /**
> * @see ResultSetMetaData#getTableName(int)
> */
> - public String getTableName(int arg0) throws SQLException {
> - notImplemented();
> - return null;
> + public String getTableName(int aColumnIndex) throws SQLException {
> + return (String)myTableNames.get(aColumnIndex-1);
> + }
> +
> + public void addTableNames(String[] allNames) {
> + if (myTableNames !=3D null) {
> + for (int i =3D 0; i < allNames.length; i++) {
> + myTableNames.add(allNames[i]);
> + }
> + }
> }
>=20
> /**
> @@ -183,8 +191,15 @@
> /**
> * @see ResultSetMetaData#getColumnClassName(int)
> */
> - public String getColumnClassName(int arg0) throws SQLException {
> - notImplemented();
> - return null;
> + public String getColumnClassName(int aColumnIndex) throws SQLExcepti=
on
> {
> + return (String)myColumnClassNames.get(aColumnIndex-1);
> + }
> +
> + public void addColumnClassNames(String[] allNames) {
> + if (myColumnClassNames !=3D null) {
> + for (int i =3D 0; i < allNames.length; i++) {
> + myColumnClassNames.add(allNames[i]);
> + }
> + }
> }
> }
>=20
>=20
> ------------------- THE DIFF END ----------------------------
>=20
> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Christian Trutz
> Sent: 16. apr=EDl 2002 16:58
> To: Mockobjects
> Subject: Re: [MO-java-dev] MockConnection
>=20
>=20
> Hi Oskar,
>=20
> some unit tests for MockResultSetMetaData would be very nice ;-)
>=20
> Christian
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: moc...@li...
> [mailto:moc...@li...]Im Auftrag von
> Oskar Hannesson
> Gesendet: Dienstag, 16. April 2002 18:34
> An: 'Jeff Martin'; 'MockObjects'
> Betreff: [MO-java-dev] MockConnection
>=20
>=20
> Hi there!
> It is nice to see the MockResultSetMetaData class finally make its way in=
to
> CVS , even though I posted similar code (+ unit test) some six months ago=
:-(
> When I started using Mockobjects last year I ran in to problems having
> multiple Statements pr. connection.
> The current version of MockConnection supports only one Statement pr.
> connection so I modified it and posted it to this group.
> The code never made it to the CVS so I ask:
> Is someone currently working on this problem or should I try to re-commit=
my
> implementation and hope for a better response ?
>=20
> I found some 8 months old code in CVS
> (mockobjects-java/src/extensions/com/mockobjects/eziba/sql) which seem to=
be
> addressing some this problem.
> Is this perhaps an upcoming version of the sql package?
>=20
> Regards
> Oskar Hannesson
> deCODE Genetics
> Addr: Sturlugata 8 , 101 Reykjavik, Iceland
> Tel: (354) 570-1900
> Fax: (354) 570-1903
> Web: www.decode.com
>=20
> PS!
> I really hate relying on my own private version of MockObjects.
>=20
>=20
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>=20
>=20
>=20
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
--=20
|
|
From: Steve F. <st...@m3...> - 2002-04-18 22:46:43
|
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 |
|
From: Jeff M. <je...@mk...> - 2002-04-19 09:06:05
|
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 -- |
|
From: Jeff M. <je...@mk...> - 2002-04-16 17:12:44
|
I don't know of any work in this area. Not sure what happened to you patches either, sorry about that. If you resubmit your code I'll try and look at it when I get a chance. On Tue, 2002-04-16 at 17:33, Oskar Hannesson wrote: > Hi there! > It is nice to see the MockResultSetMetaData class finally make its way in to > CVS , even though I posted similar code (+ unit test) some six months ago:-( > When I started using Mockobjects last year I ran in to problems having > multiple Statements pr. connection. > The current version of MockConnection supports only one Statement pr. > connection so I modified it and posted it to this group. > The code never made it to the CVS so I ask: > Is someone currently working on this problem or should I try to re-commit my > implementation and hope for a better response ? > > I found some 8 months old code in CVS > (mockobjects-java/src/extensions/com/mockobjects/eziba/sql) which seem to be > addressing some this problem. > Is this perhaps an upcoming version of the sql package? > > Regards > Oskar Hannesson > deCODE Genetics > Addr: Sturlugata 8 , 101 Reykjavik, Iceland > Tel: (354) 570-1900 > Fax: (354) 570-1903 > Web: www.decode.com > > PS! > I really hate relying on my own private version of MockObjects. > > > _______________________________________________ > Mockobjects-java-dev mailing list > Moc...@li... > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev -- |
|
From: Oskar H. <osk...@de...> - 2002-04-17 10:46:26
|
Hi again... I checked out the latest code from CVS and found that Multiple PreparedStatement pr. connection have been implemented. The code I based my changes on was an old one from August 2001. I did however run my precious unit test against it and found that this code does not handle Multiple Statements pr. connection. Maybe I post some changes to this in coming days so I can escape my own private MockObject world. Regards Oskar H. -----Original Message----- From: moc...@li... [mailto:moc...@li...]On Behalf Of Jeff Martin Sent: 16. apr=EDl 2002 17:09 To: 'MockObjects' Subject: Re: [MO-java-dev] MockConnection I don't know of any work in this area. Not sure what happened to you patches either, sorry about that. If you resubmit your code I'll try and look at it when I get a chance. On Tue, 2002-04-16 at 17:33, Oskar Hannesson wrote: > Hi there! > It is nice to see the MockResultSetMetaData class finally make its way in to > CVS , even though I posted similar code (+ unit test) some six months ago:-( > When I started using Mockobjects last year I ran in to problems having > multiple Statements pr. connection. > The current version of MockConnection supports only one Statement pr. > connection so I modified it and posted it to this group. > The code never made it to the CVS so I ask: > Is someone currently working on this problem or should I try to re-commit my > implementation and hope for a better response ? > > I found some 8 months old code in CVS > (mockobjects-java/src/extensions/com/mockobjects/eziba/sql) which seem to be > addressing some this problem. > Is this perhaps an upcoming version of the sql package? > > Regards > Oskar Hannesson > deCODE Genetics > Addr: Sturlugata 8 , 101 Reykjavik, Iceland > Tel: (354) 570-1900 > Fax: (354) 570-1903 > Web: www.decode.com > > PS! > I really hate relying on my own private version of MockObjects. > > > =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 -- =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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X