Proposed Plan (6.27.05)

Not much has been added in terms of new functionality for M5. Most of the work done was in the areas of refactoring, cleaning up dead code, and cleaning up APIs. Also more unit tests were added which are run regularly with the build.

The M4 test plan should have sufficient coverage for M5.

We will inspect "runtime" version of build to be sure extra source is not included, and more important, we'll inspect and test importing SDK version to be sure all relevant "open source" is included in that SDK build and that it correctly imports into a development environment.

Here in M5 we don't consider we have any official API yet (since not spec'd as such) but will reserve this space for future plans to details were API Unit tests are, their coverage, etc.

We do have several hundred unit tests which we expect to be running and passing for M5, which test various aspects of parsing, model creation, and correct charset handling, among other things.

The nature of the end-user testing is intentionally planned to be "ad hoc" instead of specifying step by step "how to" directions and specific "expected results" sections often seen in test cases. This is done because its felt leads to greater number of "paths" being tested, and allows end-users more motivation for logging "bugs" if things didn't work as they expected, even if it is working as designed.

As we progress through milestones, we'll add more and more detail for special cases, special files, special projects, etc.When we do have special or sample test files and projects, we will keep those stored in CVS, as projects under a testdata directory under the development directory of relevant component so that testers (from immediate team, or community) can easily check out into the environment being tested.

While we do not have any platform specific code, or function, we will have some team members do end-user tests on Linux, some on Windows. We will also confirm unit tests pass on both platforms.

We have added (some) automated performance tests along the lines of the Eclipse base performance unit tests in future milestones. These are currently in the org.eclipse.wst.*.ui.tests.performance and org.eclipse.jst.jsp.ui.tests.performance plugins

We will continue to add more test cases in upcoming milestones.

• check Source Editing features from feature matrix
• A quick sanity check that preferences have effect, and do no harm. Only quick check, since many changes planned in this are for future milestones.

• hyperlink open on:
• preferences:
  • how we use the preferences in the "All Text Editors" preference page now.
  • make sure preferenes work
  • after shutdown and restart
• profiling:
  • using your favorite profiler (XRay, YourKit, etc...) test basic editor functions and look for problem areas (large memory consumption, intense CPU usage)

DTD Validation(batch only)

New File Wizard

• make sure the template creates a valid file

Tab Preferences

• Web and XML->Content Type Files -> Content Type Source -> Indent using tabs / Indent using spaces -> Indentation size
• Verify the correct tab character is used
• Verify the correct number of tab characters is used
• Verify Source->Shift Left/Shift Right and the Shift-Tab/Tab key follow the preferences
• With nothing selected
• With multiple lines selected
• Verify Format follow the preferences
• Verify when using tab characters, the displayed tab width preference is followed (General->Editors->Text Editors -> Displayed tab width)

Formatting tests

org.eclipse.wst.sse
org.eclipse.wst.xml
org.eclipse.wst.html
org.eclipse.wst.css
org.eclipse.wst.dtd
org.eclipse.wst.javascript
org.eclipse.jst.jsp