db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Created: (DERBY-1555) API for configuration information in Derby's JUnit tests should through instance methods of the base classes, not static methods and static fields
Date Fri, 21 Jul 2006 19:08:40 GMT
Myrna van Lunteren wrote:

> On 7/20/06, Daniel John Debrunner (JIRA) <derby-dev@db.apache.org> wrote:
> 
>> API for configuration information in Derby's JUnit tests should
>> through instance methods of the base classes, not static methods and
>> static fields

> Hi Dan,
> 
> I dimly grasp what you mean, but could you ellaborate with an example
> where the current usage could be written using an instance based
> scheme and how that could allow expanded testing?

Yes, my comments in the issue were not clear, but to some extent I'm
going on gut feeling. Java is an OO language, and static fields & fields
are not the best pattern in OO languages. Instance fields/state and
methods allow a lot more flexibility, even if at this point in time we
are not sure how it could be used.

As an example the getConnection method in BaseJDBCTestCase, currently
it's static based upon the fact there's a single static configuration.
An instance method would allow more flexiblity in that a test class
could override it to tailor the connection for its set of tests, such as
ensuring every connection is always in a specific schema and/or has the
correct isolation level, etc. Now you could say it could be done today
by just adding an instance method in the specific test class and then
using that method, but then you force the developer to have to choose
between one method or the other, leading to the potential that the
incorrect method is used (especially when copy&paste is a typical
development model). This approach also causes problem when you want to
share code between multiple tests, re-use of common components etc.

The expanded testing I see in the future is as simple as stress testing
by running multiple JUnit suites in parallel within the same JVM. Having
those runs forced to share a single configuration really restricts the
testing. Imagine running concurrent language suites, one as normal, one
with encryption, one with Japanes locale etc.

Hope this helps,
Dan.


Mime
View raw message