Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Development/Testing/DatabaseCertification"
(→Concerns: Added two ideas regarding TCK compliance certification) |
|||
| Line 36: | Line 36: | ||
* How do we certify JPA TCK compliance for database we cannot test on-site | * How do we certify JPA TCK compliance for database we cannot test on-site | ||
| + | ** Ask DB vendor to make a copy available for this purpose. As certification is only applied for once for a release, the overhead of running the TCK on extra DBs can be overseen. (The DB vendor might agree to having the database used for a longer period for continuous regression testing purposes.) | ||
| + | ** Ask DB vendor to make the database available off-site (remotely available). As certification is only applied for once for a release, the inconvenience of not having direct access to the database might be acceptable. | ||
Revision as of 08:21, 8 September 2009
Under Construction
This page is a work in progress. Please feel free to add any ideas you think are helpful. The end goal is to provide a well-defined set of tests that can easily be run by anyone that wants to contribute a subclass of DatabasePlatform in order to determine if that DatabasePlatform can be certified as part of the EclipseLink product. Note: Actual certification of the DatabasePlatform should be handled through the incubation process: EclipseLink/Development/Incubator
Current State
There are two frameworks of interest
JPA testing
The current set of JPA tests includes both basic tests and advanced tests. The way we certify database platforms is to run the whole suite and individually identify tests that should log warnings instead of failing.
Foundation testing
There is no simple way to certify a DatabasePlatform using the foundation testing framework. The SRG is too-small a test set and the LRG is too large a test-set.
End Goal
The end goal is to have a single build target that runs a test suite that is composed of the following:
- A set of JPA tests that is expected to run on every database we certify
- A set of foundation tests that is expected to run on every database we certify
Additionally, we will need a way to identify advanced tests that should run on a database-by-database basis
Ideas
- In foundation, create a test suite in a similar way to the way we create the SRG test suite.
- Your idea here
Concerns
- How do we certify JPA TCK compliance for database we cannot test on-site
- Ask DB vendor to make a copy available for this purpose. As certification is only applied for once for a release, the overhead of running the TCK on extra DBs can be overseen. (The DB vendor might agree to having the database used for a longer period for continuous regression testing purposes.)
- Ask DB vendor to make the database available off-site (remotely available). As certification is only applied for once for a release, the inconvenience of not having direct access to the database might be acceptable.