9:59 a.m.
I would like to refactor AbstractMMQueryTestCase by pushing its core
logic further down (new base class) for executing queries, comparing
results, and common actions on the connection, etc. so that it can
reused (extended) for any manner of tests that, in the end, use a
Connection. Also, this core logic is basic to jdbc testing and
therefore would like to reuse this in the, soon to becoming,
integration test project for testing transactions and running the ctc
tests. There was already a similar class, from whence it came
from, in the JBEDSP integration test project. So I would to
consolidate this logic.
Any comments, complaints, suggestions, please speak up. Otherwise I
will commence with refactoring tomorrow.
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
10:23 a.m.
Van,
This class is utility class, in most situations it is extended by a
another class to write the test.
If you are looking to to provide abstractions for connections you can
certainly/override the "getConnection" calls or add others. You can
refactor to suit the needs, I just wondering if that requires pushing
the functionality to a base class (as this is already functionally a
abstract class)?
Thanks
Ramesh..
On Thu, 2009-08-27 at 09:59 -0500, Van Halbert wrote:
I would like to refactor AbstractMMQueryTestCase by pushing its core
logic further down (new base class) for executing queries, comparing
results, and common actions on the connection, etc. so that it can
reused (extended) for any manner of tests that, in the end, use a
Connection. Also, this core logic is basic to jdbc testing and
therefore would like to reuse this in the, soon to becoming,
integration test project for testing transactions and running the ctc
tests. There was already a similar class, from whence it came
from, in the JBEDSP integration test project. So I would to
consolidate this logic.
Any comments, complaints, suggestions, please speak up. Otherwise I
will commence with refactoring tomorrow.
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
_______________________________________________
teiid-dev mailing list
teiid-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/teiid-dev
10:37 a.m.
This is the net result of how the AbstractMMQueryTestCase would end
up, because these are directly dependent on using the DriverManager:
static {
new TeiidDriver();
}
private Stack<com.metamatrix.jdbc.api.Connection> contexts = new
Stack<Connection>();
public void pushConnection() {
this.contexts.push(this.internalConnection);
this.internalConnection = null;
}
public void popConnection() {
this.internalConnection = this.contexts.pop();
}
public com.metamatrix.jdbc.api.Connection getConnection(String
vdb, String propsFile){
return getConnection(vdb, propsFile, ""); //$NON-NLS-1$
}
public com.metamatrix.jdbc.api.Connection getConnection(String
vdb, String propsFile, String addtionalStuff){
closeResultSet();
closeStatement();
closeConnection();
try {
this.internalConnection = createConnection(vdb, propsFile,
addtionalStuff);
} catch (SQLException e) {
throw new RuntimeException(e);
}
return this.internalConnection;
}
public static com.metamatrix.jdbc.api.Connection
createConnection(String vdb, String propsFile, String addtionalStuff)
throws SQLException {
String url = "jdbc:metamatrix:"+vdb+"@" + propsFile
+addtionalStuff; //$NON-NLS-1$ //$NON-NLS-2$
return
(com.metamatrix.jdbc.api.Connection)DriverManager.getConnection(url);
}
protected void helpTest(String query, String[] expected, String
vdb, String props, String urlProperties) {
getConnection(vdb, props, urlProperties);
executeAndAssertResults(query, expected);
closeConnection();
}
With these changes, tt would enable the extender to control how the
connection is created (i.e., from the MMDataSource).
Van
On Aug 27, 2009, at 10:23 AM, Ramesh Reddy wrote:
Van,
This class is utility class, in most situations it is extended by a
another class to write the test.
If you are looking to to provide abstractions for connections you can
certainly/override the "getConnection" calls or add others. You can
refactor to suit the needs, I just wondering if that requires pushing
the functionality to a base class (as this is already functionally a
abstract class)?
Thanks
Ramesh..
On Thu, 2009-08-27 at 09:59 -0500, Van Halbert wrote:
> I would like to refactor AbstractMMQueryTestCase by pushing its core
> logic further down (new base class) for executing queries, comparing
> results, and common actions on the connection, etc. so that it can
> reused (extended) for any manner of tests that, in the end, use a
> Connection. Also, this core logic is basic to jdbc testing and
> therefore would like to reuse this in the, soon to becoming,
> integration test project for testing transactions and running the ctc
> tests. There was already a similar class, from whence it came
> from, in the JBEDSP integration test project. So I would to
> consolidate this logic.
>
> Any comments, complaints, suggestions, please speak up.
> Otherwise I
> will commence with refactoring tomorrow.
>
>
> Van Halbert
> Principal Software Eng.
> Red Hat, Inc.
> ------
> vhalbert(a)redhat.com
>
>
>
>
> _______________________________________________
> teiid-dev mailing list
> teiid-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/teiid-dev
Van Halbert
Principal Software Eng.
Red Hat, Inc.
------
vhalbert(a)redhat.com
5595
days inactive
5595
days old
2 comments
2 participants
participants (2)
-
Ramesh Reddy -
Van Halbert