Limit external Tomcat & Derby tests to startup verification#7252
Limit external Tomcat & Derby tests to startup verification#7252samyoon20 wants to merge 8 commits into
Conversation
92d9d1e to
cd554fe
Compare
|
@smlambert Hi! When you have time, could I get a review of the direction I'm heading with the test approach I have for tomcat and derby tests? I have two tests that I used as our standard example that if idea is good, we could apply directly to the other related external tests that are listed above. I used disable but so if we were to run the full suite, we would have to remove the disables and also have to add ant test back into test.sh https://ci.adoptium.net/job/Grinder/17568/ tomcat_startup_test: derby_startup_test: |
d7e82f1 to
4f7fb22
Compare
Replace full junit-all test suite with startup-only verification using Derby's built-in sysinfo tool. The sysinfo command exercises JVM launch, Derby class loading, and runtime reflection without running Derby's own application-level unit tests. Also fix pre-existing bash syntax bug: 'export var value' (without =) does not assign the variable in bash; corrected to 'export var=value'. - external/derby/test.sh: remove ant junit-all; fix export syntax; run java -jar derbyrun.jar sysinfo as the startup signal - external/derby/playlist.xml: add derby_startup_test at extended level; demote derby_test_junit_all to special level (on-demand only)
4f7fb22 to
d86d990
Compare
Summary
Implements startup-only verification for two external tests (Tomcat and Derby). This addresses the roadmap item listed in external/README.md — "Startup-only testing (application startup, but not full runs of app functional testing)" — and tracks issue #7243.
Changes
'external/tomcat/' - server-style startup verification
playlist.xml: Keeps tomcat_test at extended level, disabled. Remove disables block to reenable
'external/derby/' — tool-style startup verification
Reason
The full upstream test suites test the applications themselves, not the JDK. A failure in a Tomcat or Derby unit test is almost certainly an application-level issue, not a JDK defect. What Adoptium needs to verify is: can this JDK launch this application without crashing? A startup check that's much faster than running entire test suite
This is the first "attempt/implementation" of the startup-only pattern listed in 'external/README.md' as planned improvement
Phase 2 -> extending to the other tests that follow similar patterns
The tool-style pattern extends directly to:
The server-style pattern extends directly to:
Parts assisted by IBM Bob