|
EclipseLink is a new environment and no decisions have
been made on the architecture of our automated testing. There's nothing
that says the testing structure in EclipseLink will be the same as ADE and I
expect that it will be different. Currently testing in EclipseLink is
through the testing browser or ant scripts that pass properties as system
properties. If your tests depends on this other framework (extensions,
property files) they will not even be runnable as part of our current
testing?
Going
forward limiting the number of frameworks we have in testing will limit the
confusion for new contributors and committers.
In
regard to Peter's email has the new feature been reviewed by anyone prior to
checkin to ADE?
--Gordon
Gordon Yorke
wrote:
So, core tests are being introduced that depend on this
custom JUnit code (component?) and JUnit 4? When did the
Architecture Committee decide to integrate these JUnit 4 extensions into the
eclipselink.core testing. Have we even discussed how our testing
framework will look in Eclipse?
--Gordon
As part of the work to merge DBWS code into
EclipseLink, some IPzilla CQ's (specifically
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=1768
and 1755) were create to enable the use
of the pb4 custom
JUnit4 Runner and Ant task. Not only are there DBWS tests that
require
this capability, but also new core feature tests for supporting
non-JDBC arguments to StoredProcedures.
This is the first time in
EclipseLink that multiple components required some utility or library. To
deal
with this, I propose a new 'common' project - the directory
structure would be as
follows:
${eclipselink-svn-directory-root}
+---branches
\---trunk
|
about.txt
|
...
|
(new) +---common
-
| \---eclipselink.common
-
| | | .classpath
-
| | |
.project
- | |
|
- | |
+---lib
- | |
|
ant.jar
(CQ 1768)
- | |
|
junit4-ext-pb4.jar
(CQ 1755)
- | |
|
${other_commonly_used}.jar (future
CQ)
- | |
\---pb4
(new) |
| \--- ...
(old)
+---dbws
|
+---eclipselink.dbws
| | |
.classpath
|
| |
.project
|
| |
| |
\---src
|
|
\---org
|
|
\---eclipse
|
|
\---persistence
|
|
+---dbws
|
|
|
...
|
...
(old)
+---foundation
|
+---eclipselink.core
| | |
.classpath
|
| |
.project
|
| |
| |
\---src
|
| \--- ...
From a
developer's view inside of an Eclipse IDE environment, the main projects
(such as eclipselink.dbws , eclipselink.core and
eclipselink.moxy ) depend apriori upon
eclipselink.common . The other change will be relying upon
version 4 of the JUnit library - this
should not affect any code as the
old JUnit 3.8.x APIs are preserved in
JUnit4.
When I attended 'Architecture Committee'
meetings a few months ago, there were a number of rather vague discussions
about the
future of testing ...
With respect to JUnit4,
originally the requirement was for DBWS testing - I needed capabilities
that existing testing frameworks
available in ADE did not have (the pb4 custom JUnit4 runner allows access to env.properties and titl.properties
at runtime). However,
subsequent work on a new feature - "support non-JDBC args for
StoredProcedures" which was
inspired by DBWS but is not
actually a part of it - has tests that use pb4. The new feature is checked in as per the
message
"RE: EclipseLink and TOPLINK_MAIN_GENERIC_070821.1600"; therefore,
the tests should be checked in too.
BTW - since the new feature is
Oracle specific, the tests should probably go into
eclipselink.extension.oracle.test
--  Mike Norman
| Principal Software Designer | 613.288.4638
Oracle Server Technologies |
TopLink Product
45 O'Connor Street, Suite 400 | Ottawa, ON K1P 1A4 | (fax)
613.238.2818
|
