castor

New test framework for castor persistence

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1
  • Fix Version/s: 1.2
  • Component/s: JDO tests
  • Labels:
    None
  • Number of attachments :
    4

Description

Our current test framework lacks some important features:

  • tests are not true junit test
  • it still tests JDO instead of JDOManager
  • it does not support multiple configurations
  • related to the number of supported databases the test configuration file is very long
  • a new test needs to be added for every supported database separately

I'd therefore suggest a new configuration file of which I will attach DTD, XSD and example configuration soon.

Attachments

  1. Text File
    patch-C1906-20070312.txt
    12/Mar/07 6:45 PM
    35 kB
    Ralf Joachim
  2. Text File
    patch-C1906-20071222.txt
    22/Dec/07 9:20 AM
    254 kB
    Ralf Joachim
  3. File
    testconf.dtd
    01/Apr/07 8:05 AM
    8 kB
    Ralf Joachim
  4. XML File
    testconf.xml
    01/Apr/07 8:05 AM
    6 kB
    Ralf Joachim

Issue Links

This issue is depended upon by:
CASTOR-2237 Refactor available tests to use the new castor persistence test framework Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ralf Joachim added a comment -

Patch with new test suite configuration.

Show
Ralf Joachim added a comment - Patch with new test suite configuration.
Hide
Permalink
Ralf Joachim added a comment -

At castor meeting in Vienna we discussed about test framework for Castor persistence. We decided that the new test framework should allow test cases to be executed with junit out of the box and rely on junits mechanism to collect all tests within a package. The test framework have to provide some means to exclude tests from being executed for specific database engines. This should be achived at collection of test methods in the test cases suite method. Apart of the exclusion mechanism the test case need to provide a unique identity and a description.

Even if it will be posible to execute tests without parameters, should it also be possible to pass some parameters:

  • database: The database to execute the tests with (e.g. mysql)
  • driver: The database driver to be used (e.g. datasource)
  • transaction: The transaction demarcation to be used (e.g. local)
  • force: Force test execution even if excluded.

If executed without parameters, default values for every parameter are used.

While Werner prefered database configurations to be dynamically created with code in test case, I prefer to offer a possibility to define them at a configuration file. My idea is to load one of the predifined configurations by name from the configuration file. Having said that I also like to offer a possibility for dynamic creation in addition to the predefined ones. You'll find a DTD and an example configuration attached for review.

Show
Ralf Joachim added a comment - At castor meeting in Vienna we discussed about test framework for Castor persistence. We decided that the new test framework should allow test cases to be executed with junit out of the box and rely on junits mechanism to collect all tests within a package. The test framework have to provide some means to exclude tests from being executed for specific database engines. This should be achived at collection of test methods in the test cases suite method. Apart of the exclusion mechanism the test case need to provide a unique identity and a description. Even if it will be posible to execute tests without parameters, should it also be possible to pass some parameters:
  • database: The database to execute the tests with (e.g. mysql)
  • driver: The database driver to be used (e.g. datasource)
  • transaction: The transaction demarcation to be used (e.g. local)
  • force: Force test execution even if excluded.
If executed without parameters, default values for every parameter are used. While Werner prefered database configurations to be dynamically created with code in test case, I prefer to offer a possibility to define them at a configuration file. My idea is to load one of the predifined configurations by name from the configuration file. Having said that I also like to offer a possibility for dynamic creation in addition to the predefined ones. You'll find a DTD and an example configuration attached for review.
Hide
Permalink
Ralf Joachim added a comment -

New patch with all requested features.

Show
Ralf Joachim added a comment - New patch with all requested features.
Hide
Permalink
Ralf Joachim added a comment -

Patch commited as is.

Show
Ralf Joachim added a comment - Patch commited as is.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.