Myrna van Lunteren wrote: > On 7/20/06, Daniel John Debrunner (JIRA) <[email protected]> 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.
