Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-dev] Minutes: EclipseLink test strategy discussion

Meeting: EclipseLink test strategy discussion
Date: 2007/12/06
Attendees: David Twelves, Mike Norman, James Sutherland, Chris Delahunt, Blaise Doughan, Gordon Yorke, Mike Keith
 
Minutes
 
This meeting was aimed at identifying the main goals that should drive creation of an overall test strategy for EclipseLink.
 
Current situation
  • Existing test frameworks (loosely based on components) are not always consistent across the following areas:-
    1. Test packaging hierarchy
    2. Set of properties files that need to be modified before running test suites
    3. Method of executing test suites
    4. Test frameworks on which tests are currently written
  • The above are largely a result of each component having different testing needs (eg. MOXy currently has no requirement to run server or database tests)
Goals for an overall EclipseLink test strategy
  • A consistent user experience should be provided for contributors wishing to write and exercise tests across EclipseLink components.
  • A contributor needs to be able to easily add and run tests when submitting a patch.  We need to give them the power to easily be able to do that.
  • To achieve the above, components should align with a standardized EclipseLink test strategy. 
    1. Location of ant scripts and other utilities should be standardized in SVN.
    2. Standard configuration of tests through property files, where possible.
    3. Standard method of executing component test suites via high-level ant tasks.
    4. SRG/LRG test suites should exist for each component, which can be rolled up to a high level SRG/LRG for the product as a whole.
    5. Test output format should ideally be standardized
  • It is acknowledged that migration of all the existing test frameworks to newer platforms (eg. JUnit4) would be a significant amount of work.  This is particularly true for some of the ORM tests in the foundation component. However, this is thought to be acceptable given that
    • It is likely that individual contributors will typically focus on one component
    • Test creation guidelines can be documented for each component.  For example, contributors will be encouraged to create JUnit tests using JPA API, rather than creating new tests in the older test framework in the Foundation component.
Next steps
  • New backlog item: One committer to develop a proposal for a consistent test strategy across components, addressing items 1-5 above.  This is currently unstaffed.
  • This proposal should also include the developer test process to be followed for writing and running tests.
  • Once this is in place, each component area needs to examine what work is required in each area to conform to this proposal.  Each component should also document any differences from the standard test process.  This will include capturing required work items and detailed estimates.
 

Back to the top