Kristian Waagan wrote:
Answering these by mail, not Jira comment, as it is not the best way to
answer a lot of specific questions. Maybe I'll condense the discussion
and add a Jira comment later.
Just to be clear, I do not primarily work on this issue. I just wanted
to bring out comments to get things started, and it does seem people
have some.
David Van Couvering (JIRA) wrote:
[
http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370400
]
David Van Couvering commented on DERBY-919:
-------------------------------------------
I think it is great to have base unit test like this, although I agree
with Andreas that this should be renamed. This class is almost solely
about obtaining connections using different frameworks, and is very
JDBC-specific. There are plenty of unit tests that have no need for
this functionality.
Yes, indeed. But then we are *almost* back to simply extending TestCase.
What tests not related to frameworks (and thus JDBC) need some kind of
common functionality? Including JDBC in the name seems like a solution.
Do we agree that non-JDBC tests should extend TestCase directly?
I think it would be good to have a BaseTestCase which has access to the
following:
* a TestConfiguration object
* and possibly some debug methods to log stack trace, print stuff.
BaseJDBCTestCase could extend this with some getConnection() methods.
I am not sure how this work integrates with/coincides with the work
Andreas did to create a junit test type which allows you to run 'raw'
JUnit tests under the harness. Can you explain?
I think this work integrates well with the work to run tests a .junit.
You can confirm that by trying to run the sample testcase as .junit.
Andreas' work for running a "raw" JUnit test under the harness is not
affected. This is all about getting a connection and some other basic
functionality. It was written because the existing DerbyJUnitTest need
additional methods calls before getConnection() returns a valid
connection, and because TestUtil does not have a getConnection() (but
several other getConnection(arguments) methods). We have several choices:
* Use TestUtil, maybe do some additional work on it.
* Adapt/change DerbyJUnitTest (dependencies restrict what we can change
of existing API/behavior)
* Write a new common class from scratch
So far most of the comments I have received have been regarding
implementation, which was not my primary goal. Do we all agree what we
need, but we want to do it in different ways? Or are there still someone
out there that have more fundamental issues to comment on?
I want:
BaseTestCase: a useful base TestCase which provides a TestConfiguration
object, and some logging method
BaseJDBCTestCase: extends BaseTestCase, and additionally provides
getConnection() methods.
How the getConnection() methods are implemented, is not the important
issue to me. They may be implemented by calling TestUtil or implemented
in the BaseJDBCTestCase itself. I do however think it is important to
avoid forcing testcases to call methods to clean up potential
side-effects from previous testcases.
Also, to run a TestCase as a test of type .junit, the testcase suite
must be able to run stand-alone in a standard JUnit TestRunner .
<..>
- There are a lot of defaults being setup in a hardcoded fashion in
resetState(). It would be better to have a section of static finals
at the top with all the default values so that someone looking at this
code can tell right away what they are. Actually, looking at Andreas'
TestConfiguration, that is a nice way of doing it . Having it as a
separate class also seems to be useful and more coherent.
One note here, is that it would not be possible to change the framework
with the current TestConfiguration. This would cause trouble for
exceptional cases (as the current JDBC4 testsuite) and if we want to run
useprocess=false and switch framework. Is this switching of framework
something we don't need?
I do not see that we need switching framework in general. And .junit
tests cannot be run with useprocess=false.
I think if you additionally supplied a getConnection(..) method which
takes JDBCClient parameter, you could easily write special purpose
testcases which do not use the default framework for getting the
connectiom, if that is what you need.
Also, it seems the harness uses all of "hostName", "derbyTesting.serverhost" and
"derbyTesting.clienthost". Can anyone shed some light on this?
I assume that derbyTesting.serverhost is the hostname for the derby
server, derbyTesting.clienthost is the hostname for the client.
Andreas
