platform-vcm-home/2_1_testing.html
Parent Directory
| 
Revision Log
Revision 1.1 -
(download)
(as text)
(annotate)
Mon Feb 24 15:52:21 2003 UTC (6 years, 9 months ago) by mvalenta
Branch: MAIN
Mon Feb 24 15:52:21 2003 UTC (6 years, 9 months ago) by mvalenta
Branch: MAIN
*** empty log message ***
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<link rel="stylesheet" href="http://dev.eclipse.org/default_style.css" type="text/css">
<title>Team Testing Roadmap</title>
<meta name="author" content="OTI Employee">
<meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type">
</head>
<body>
<h1>Section 1: General CVS Tests</h1>
<h2>CVS Repositories View</h2>
<h3>Adding and Discarding Locations</h3>
These test require an existing repository which contains projects.
<ol>
<li>Add a location to the view.</li>
<li>Ensure that invalid location information is handled properly in the New Location Wizard.</li>
<li>View location properties page and ensure that information is correct and can be changed.</li>
<li>Also change property values when local projects are shared with the location and ensure
the project's sharing information is changed when the location's properties are changed.
<li>Discard a location and ensure it is removed. Also ensure that discarding is not permitted when
projects in the local workspace are shared with the location.</li>
</ol>
<h3>Project Checkout</h3>
These test require an existing repository which contains projects, at least one of which
does not contain a .project file. Ensure that repeating each operation results in the proper overwrite prompting.
<ol>
<li>Perform "Checkout as Project" on a single project. Ensure that repeating results in overwrite prompt.</li>
<li>Perform "Checkout as Project" on multiple projects.</li>
<li>Perform "Checkout as..." on a single project (that contains a .project file) and enter custom name and/or custom location.</li>
<li>Perform "Checkout as..." on a single remote project that does not have a .project file and
ensure that the user is prompted for the project type to create.</li>
<li>Perform "Checkout as..." on multipe projects and enter a custom parent location.</li>
</ol>
<h3>Browsing Tags</h3>
These test require an existing repository which contains projects that have been tagged with both
version and branch tags.
<h4>Refresh Branches and Versions</h4>
<ol>
<li>Select a repository location and perform "Refresh Branches and Versions...".
<li>Select one or more projects that contain a .project file and have been tagged with branch and version tags and click finish.</li>
<li>Expand the respository entry to view ...
<ul>
<li>projects in HEAD,</li>
<li>branches and projects in BRANCHES,</li>
<li>projects and versions in VERSIONS.</li>
</ul>
</ol>
<h4>Configure Branches and Versions</h4>
<ol>
<li>Select a project in the repositories view and perform "Configure Branches and Versions...".
<li>Select some branch and version tags to be remembered.</li>
<li>Expand the respository entry to view ...
<ul>
<li>projects in HEAD,</li>
<li>branches and projects in BRANCHES,</li>
<li>projects and versions in VERSIONS.</li>
</ul>
</ol>
<h3>Working with modules</h3>
These tests require a CVSROOT/modules file on the server that contains valid module definitions.
<ol>
<li>Switch the Repositories View and ensure that the modules are displayed properly.</li>
<li>Perform "Checkout as Module" and ensure that the module is checkout out properly.
Also ensure that repeating results in overwrite prompt.</li>
<li>Perform a "Configure Branches and Versions" on the module, set the autorefresh file and add some tags.
Ensure that the module now appears properly in association with those tags.</li>
</ol>
<h2>Project Sharing</h2>
<h3>Project sharing and disconnecting</h3>
<ol>
<li>Sharing with no CVS folders against existing project</li>
<li>Sharing with CVS folders</li>
<li>Sharing new project with no CVS folders</li>
<li>Disconnect: keeping and deleting CVS folders, reconnecting (as above)</li>
</ol>
<h3>Project sets</h3>
<ol>
<li>Create one, delete projects, load set and ensure got projects back</li>
<li>Test against HEAD, project on branch/version.</li>
</ol>
<h2>CVS workflow</h2>
<h3>Common workflows</h3>
To perform the tests properly, check out the same remote project into two local projects.
<ol>
<li>Commit and Update with incomming, outgoing and conflicting changes and ensure proper behavior.</i>
<li>Update/commit with very large files (> 8 meg)</li>
<li>Replace with (latest, base, branch, version, revision)</li>
<li>Compare with (latest, base, branch, version, revision)</li>
<li>Ensure you are prompted for unsaved changes before performing a CVS action</li>
<li>Tag as Version and ensure that remote is tagged properly.</li>
<li>Tag as Version with dirty local resources and ensure proper prompting.</li>
<li>Change ASCII/Binary Property on projects and resources and ensure proper behavior.</li>
</ol>
<h3>Ignoring resources</h3>
<ol>
<li>Ignoring resources</li>
<li>“Add to .cvsignore”</li>
<li>Add to global ignore list, ensure its now ignored</li>
</ol>
<h3>Global Actions</h3>
Test the following CVS global actions in the CVS Repository Exploring perspective.
<ol>
<li>Synchronize All</li>
<li>New Repository Location</li>
</ol>
<h3>Decorators</h3>
<ol>
<li>Change all the options, apply, see them redraw correctly</li>
<li>Add/remove items, ensure dirty markers update</li>
<li>Add to version control and see decorator change</li>
<li>Performance with large trees expanded</li>
<li>Collapse large tree, exit workspace, restart (should not be as expensive
as if tree had been left expanded)</li>
</ol>
<h3>Patching</h3>
Creating patches and then comparing with them. In particular,
<ol>
<li>added files</li>
<li>deleted files</li>
<li>added or deleted folders with added or deleted files in them</li>
<li>binary files</li>
</ol>
<h3>Watch/Edit</h3>
<ol>
<li>Turn on watch/edit in preferences (Team/CVS/Watch/Edit)</li>
<li>Turn on the CVS decorators
<li>Check out a project and ensure all files are read-only</li>
<li>Open a file in an editor and start typing. Ensure that decorator an file changes and file is no longer read-only.</li>
<li>Perform a Team/Show CVS Editors on the file and/or project.</li>
<li>Perform a Team/Unedit on the file to ensure that file is returned to base contents and is read-only.
(or perform a Team/Commit and ensure the file is returned to being read-only).</li>
</ol>
<h3>Working with Modules</h3>
These test require valid moduel definitions in the CVSROOT/modules file of the repository
<ol>
<li>Checkout a module and ensure success.</li>
<li>Perform other CVS tests on the local project as if it were a regular project.</li>
</ol>
<h3>Misc</h3>
<ol>
<li>Mixing tags within a project.</li>
<li>Properties pages for projects, folders and files.</li>
<li>CVS Console: ensure written to</li>
<li>Check canceling everywhere there's a progress monitor</li>
<li>Does it cancel in reasonable time?</li>
<li>Is the workspace in an ok state after?</li>
<li>Compression switches, ensure data transfered ok (commit, update)</li>
</ol>
<h1>Section 2: CVS Synchronize View</h1>
<table height="124" border="1" width="99%">
<tbody>
<tr>
<td width="25%"><b>Change Type</b></td>
<td width="25%"><b>Action</b></td>
<td width="50%"><b>Result</b></td>
</tr>
<tr>
<td width="25%"><b>Incoming File Change</b></td>
<td width="25%">Update</td>
<td width="50%">Remote contents become local. Try with both Text and
Binary files.</td>
</tr>
<tr>
<td width="25%"><b>Incoming File Change</b></td>
<td width="25%">Override and Commit</td>
<td width="50%">Only in Both mode. Prompt for release comment. Cancel
aborts, OK commits local file to server.</td>
</tr>
<tr>
<td width="25%"><b>Incoming File Addition</b></td>
<td width="25%">Update</td>
<td width="50%">Remote contents become local. Try with both Text and
Binary files.</td>
</tr>
<tr>
<td width="25%"><b>Incoming File Addition</b></td>
<td width="25%">Override and Commit</td>
<td width="50%">Only in Both mode. Prompt for release comment. Cancel
aborts, OK commits deletion to server.</td>
</tr>
<tr>
<td width="25%"><b>Incoming File Deletion</b></td>
<td width="25%">Update</td>
<td width="50%">Local file is deleted.</td>
</tr>
<tr>
<td width="25%"><b>Incoming File Deletion</b></td>
<td width="25%">Override and Commit</td>
<td width="50%">Only in Both mode. Prompt for release comment. Cancel
aborts, OK commits local file to server.</td>
</tr>
<tr>
<td width="25%"><b>Outgoing File Change</b></td>
<td width="25%">Commit</td>
<td width="50%">Prompt for release comment. Cancel aborts, OK commits
local file to server.</td>
</tr>
<tr>
<td width="25%"><b>Outgoing File Change</b></td>
<td width="25%">Override and Update</td>
<td width="50%">Only in Both mode. Remote contents become local. Try
with both Text and Binary files.</td>
</tr>
<tr>
<td width="25%"><b>Outgoing File Addition</b></td>
<td width="25%">Add to Version Control</td>
<td width="50%">Adds the file to version control. The icon should change
in the sync view, and Commit should now be enabled.</td>
</tr>
<tr>
<td width="25%"><b>Outgoing File Addition</b></td>
<td width="25%">Add to .cvsignore</td>
<td width="50%">Adds the file to .cvsignore. The file should disappear
from the sync view. The .cvsignore file should appear (if it wasn't visible
already). The file should not appear in subsequent syncs.</td>
</tr>
<tr>
<td width="25%"><b>Outgoing File Addition</b></td>
<td width="25%">Commit</td>
<td width="50%">Commit is only enabled on an outgoing addition if it
has first been added to version control. Prompt for release comment. Cancel
aborts, OK commits local file to server.</td>
</tr>
<tr>
<td width="25%"><b>Outgoing File Addition</b></td>
<td width="25%">Override and Update</td>
<td width="50%">Only in Both mode. Local file is deleted.</td>
</tr>
<tr>
<td width="25%"><b>Outgoing File Deletion</b></td>
<td width="25%">Commit</td>
<td width="50%">Prompt for release comment. Cancel aborts, OK commits
deletion to server.</td>
</tr>
<tr>
<td width="25%"><b>Outgoing File Deletion</b></td>
<td width="25%">Override and Update</td>
<td width="50%">Only in Both mode. File is re-created, remote contents
become local.</td>
</tr>
<tr>
<td width="25%"><b>Conflicting File Change</b></td>
<td width="25%">Override and Commit</td>
<td width="50%">Prompt for release comment. Cancel aborts, OK commits
local file to server. Applies to both auto-mergeable and non-mergeable conflicts.</td>
</tr>
<tr>
<td width="25%"><b>Auto-mergeable Conflicting File Change</b></td>
<td width="25%">Override and Update</td>
<td width="50%">Auto-mergeable conflicts have a two-way red/green arrow.
Dialog prompts user to either auto-merge or replace. If user chooses auto-merge,
then remote changes are merged in with local changes. File should still
be dirty, local changes should still be present, CVS markup should not be
present, and no .# files should have been created. If user chooses replace,
then local changes are discarded and remote contents replace local. No .#
files created, no CVS markup, and the file is not dirty as a result. If
the user chooses cancel nothing happens.</td>
</tr>
<tr>
<td width="25%"><b>Non-mergeable Conflicting File Change</b></td>
<td width="25%">Override and Update</td>
<td width="50%">Dialog prompts user to replace local changes. If user
cancels nothing happens. If user chooses OK, then local changes are discarded
and remote contents replace local. No .# files created, no CVS markup, and
the file is not dirty as a result.</td>
</tr>
<tr>
<td width="25%"><b>Conflicting File Addition</b></td>
<td width="25%">Add to Version Control</td>
<td width="50%">Adds the file to version control. The icon should change
in the sync view, and Override and Commit should now be enabled.</td>
</tr>
<tr>
<td width="25%"><b>Conflicting File Addition</b></td>
<td width="25%">Override and Commit</td>
<td width="50%">Override and Commit is only enabled on an outgoing addition
if it has first been added to version control. Prompt to warn of conflicting
changes. If OK, prompt for release comment. Cancel aborts either dialog.
OK commits local file to server.</td>
</tr>
<tr>
<td width="25%"><b>Conflicting File Addition</b></td>
<td width="25%">Override and Update</td>
<td width="50%">Remote contents become local.</td>
</tr>
</tbody>
</table>
<h2>Variations</h2>
<h3>Container Selection</h3>
<p>Normally, selecting a folder is the same as selecting all of the individual
files underneath it. (The exception to this is if the folder itself is changed,
such as a conflicting addition). Performing any of the above operations
on a folder should behave as if the files underneath it were selected.</p>
<p>Note that if an action is not specified for a change type, it does not
apply to that change type. This is important in container selection.</p>
<p>For example: Commit does not apply to conflicting changes. If you select
a folder with an Outgoing Change and a Conflicting Change in it, Commit
will apply to the Outgoing Change but not to the Conflicting Change.</p>
<h3>Multi-Selection</h3>
<p>If multiple resources are selected, an action is enabled if it applies
to any one or more of the selected resources. Choosing that action will
apply the action only to those resources for which it is applicable.</p>
<p>For example: Commit does not apply to conflicting changes. Selecting an
Outgoing Change and a Conflicting Change will result in Commit being enabled.
Choosing Commit will apply to the Outgoing Change but not to the Conflicting
Change.</p>
<p>Multi-Selection and Container Selection may be used in any combination
with predictable results.</p>
<h2>Specific Scenaria</h2>
<h3>Making Manual Changes</h3>
<p>Create a conflicting file change. Manually edit the left source pane in
the sync view. Hit "Save" on the popup menu. The file should remain a Conflict;
you should get a prompt telling you to Mark as Merged when finished. Choose
Mark as Merged in the popup menu of the tree. The file should change to
an outgoing change. Commit the outgoing change.</p>
<h3>Merging Conflicts</h3>
<p>Try Override and Update with different combinations of Auto-Mergeable
and Non-Mergeable conflicts in the selection. If all conflicts are Non-Mergeable,
then the only choice is to replace with remote or cancel. If one or more
conflicts are Auto-Mergeable, the choices are (a) Auto-Merge any applicable
files, and replace the rest with remote, (b) Replace all files with remote
or (c) Cancel.</p>
<h3>Removing from View</h3>
<p>Choose Remove from View. Selected nodes should disappear. Refresh the
view. The nodes should reappear.</p>
<h3>Synchronize Outgoing Changes</h3>
<p>If you choose Synchronize Outgoing Changes from the navigator, the sync
view should be populated with <b>only the Outgoing Changes and Conflicts</b>
. This operation should be significantly faster in many cases. In this
case, ensure that Refresh does not cause Incoming Changes to appear.</p>
<h3>Working with Branches</h3>
<p>Try any and all of the above, but use a branch instead of HEAD. Behaviour
should be identical. The sync view decorator should show you the name of
the branch.</p>
<h3>Using Mixed Tags</h3>
<p>Using Team->Branch, Replace With->Branch or Version, and Team->Tag
as Version, you can create a project which has different tags mixed into
it. For example, one folder may be shared as V2_0, a single file may be attached
to the branch NEW_FEATURE_BRANCH, and the root of the project may be attached
to HEAD. We need to test usage of these projects in the sync view. For example,
if developer 1 has project P shared with HEAD, and folder P/F is shared
with branch B, have developer 2 release a change to folder F in HEAD, and
have developer 1 perform a sync. In this case developer 1 should not see
the incoming change.</p>
<h1>Section 3: Migration from 2.0 to 2.1</h1>
The below tests require a workspace created using 2.0 which contains
projects checked out from a CVS repository.<br>
<h3>Migrating a workspace project created using 2.0 to 2.1</h3>
<ol>
<li>Start Eclipse 2.1 on top of a workspace from 2.0</li>
<li>Select a project that was shared with a CVS repository and chose Team/Share
Project…</li>
<li>Select the Repository location to share with or enter it if it does
not appear in the list.</li>
<li>Upon finish, the user will be prompted to select either HEAD or the
branch to compare against. </li>
<li>The Synchronize view will then be opened and all files will appear
as incoming, outgoing or conflicting additions.</li>
<li>To see the real conflicts, enable “Compare File Contents” available
from the drop down menu in the title bar of the Synchronize View.</li>
<li>Resolve the real incoming, outgoing additions and conflicts as
appropriate (see sync view test plan for a description of sync state resolution)</li>
<li>When all conflicts are resolved, disable “Compare File Contents” and
perform an “Override and Update” on the remaining conflicting additions to
update the sync info of the local resources.</li>
<li>Ensure local copy contains the proper contents (can use Compare With/Latest
from Repository)<br>
</li>
</ol>
<h1>Section 4: Branching and Merging</h1>
<h2>Main branching scenario</h2>
Here's the main sequence of steps performed over the life cycle of a simple
branch.<br>
<ol>
<li>Load or create a shared project with shared content</li>
<li>Perform a Team/Branch...</li>
<li>Ensure that the tag on the local resources has been updated (either
using the CVS decorators or resource properties)</li>
<li>Make some changes to local resources and commit them (working in a branch
is similar to working in HEAD. See the Synchronize test plan for detaits).</li>
<li>Load HEAD</li>
<li>Optionaly, make some changes to HEAD (may or may not be committed)</li>
<li>Perform a Team/Merge... to merge the branch with HEAD. Merging is similar
to synchronizing but only incoming and conflicting changes are shown. See
the Synchronize test plan for detaits</li>
</ol>
<h2>Variations</h2>
<h3>Comparing branch, root version and HEAD</h3>
After any of the above steps that modify the local content or the remote
content, the success of the operation can ne validated by comparing the local
workspace copy with either HEAD, the branch or the root version specified
when creating the branch.
<h3>Branch with local changes</h3>
Before branching, make some local changes but do not commit them. Changes
can include additions and deletions. After branches ensure that the changes
are still there. On merging ensure that any created or deleted resources
appear properly in the merge editor.
<h3>Don't start working in the branch</h3>
When the branch is created, do not start working in the branch. Ensure
that the workspace was not modified but that the branch and root version
exists remotely (using Comapre With/Branch or Version...)
<h3>Branch on a folder or file</h3>
Branching can also be performed on a folder or file.
<h3>Merge from Head to a branch</h3>
Make some changes to a branch and to HEAD. Merge the changes from HEAD
into the branch before merging the branch with HEAD.
</body>
</html>
| help@eclipse.org | ViewVC Help |
| Powered by ViewVC 1.0.3 |