JDT Core / Release Candidate 1 : Testing Plan 
Release Candidate 2 test plan is available here.
Verify all RC1 fixes (David)
  • already verified
  • remaining unverified
  • ensure we did not break source compatibility with 2.0 Eclipse plugin sources (at least at API level).
2.0 backward compatibility (David, Kent)
  • ensure we can open a relocated 2.0 dev workspace (search, build, codeassist, package view)
  • take a 2.1 shared project (using classpath enhancements such as exclusion patterns, nested source folders, multiple output folders) and check it out in a 2.0 client. Do we properly ignore extra information ?
Performance (Olivier, Kent)
  • bench startup times in various modes (hierarchy view opened or not, many source plugins, many binary plugins)
  • compare various operations against several reference points (2.0.2, M4, M5): create Throwable type hierarchy, rebuild all workspace, search for references to method Collection#add().
  • check behavior of startup when previous session was interrupted abruptely, or was exited before indexing was finished
  • check speed of new source mapping, especially in conjunction with search inside binary files with attached sources (suspecting regression), maybe it should precompute all possible roots at once instead of lazily.
Reconcile with Errors (Philippe)
  • unexpected errors (concurrency issues?) when performing changes in between various open editors. If not updating properly, could be UI refresh or reconciling. Enabling trace can indicate if reconciliation diagnosis was right.
  • paste in some code highly broken (specs from design note with some sparse signatures etc...)
Java Builder (Kent, Philippe)
  • write new test scenarii
  • building cycles (incremental and full build)
  • usage of exclusion patterns
  • usage of multiple output folders
  • usage of nested source folders
Java preferences and variables (David)
  • check export/reimport of Java preferences
Classpath (Jérôme, Olivier, Kent)
  • check that forbidden scenarii are detected ok (classpath validation)
  • check cycle detection
  • check classpath problem marker update
  • check handling of corruption of .classpath file
DOM AST(Olivier, Jérôme)
  • challenge it trying various refactoring actions on corner cases and source with errors
  • check inferred quickfixes for compilation problems
Ant Java Adapter (Olivier)
  • check default settings in various mode (1.3, 1.4)
Search (Jérôme, Philippe)
  • check memory/performance scaling when lots of potential matches (e.g. references to #add())
  • check inaccurate matches (too many/not enough)
  • check if missing matches in hierarchy search, scoped search
  • check indexer crash recovery
  • check index format change recovery
Type Hierarchies (Jérôme, Olivier)
  • missing types
  • performance
Java Model (Jérôme, Philippe)
  • check delta batching
  • combinations of new features: exclusion patterns, multiple output folders: check package view rendering, delta issued
    • check shared source folders and linking prereq output folder as lib folder
  • check automatic external JAR refresh
  • check sorting members does refresh outliner (also case of occurence count >1)
  • classpath containers
    • check switching JRE (with performance in JavaModel update)
    • check deltas when switching JREs using containers
    • check deltas when restarting old workspace (should not be delta if same JRE)