VSS Profile Test Specification for Generic VCS Module
Author: Jiri Kovalsky
Version: 1.0
Last update: Wed January 7 15:10:01 CET
2004
Table of Contents
1. Introduction:
Microsoft's Visual
SourceSafe tool is one the supported version control systems in the
IDE. This document
describes how VSS profile for Generic VCS module should be tested in
order to know whether all of its commands work correctly.
Legend:
- this icon
represents a test case that is part of validation suite and is used
during Q-build
testing.
-
this icon represents a test case that was automated and is run daily in
test runtime.
Purpose: This
suite tests whether it is possible to mount VSS filesystem according to
settings
specified in mounting wizard which are defined in chosen VSS profile.
Setup: Be sure to have Microsoft Visual
SourceSafe 6.0 or higher installed on your computer with an account
created for you. Create new directory with similar contents like it is
shown at these pictures.
| Test case # |
Description |
2.1 VSS settings
available
|
1. Invoke Versioning | Mount Version Control | Generic VCS
from main menu.
2. Choose proposed VSS profile from the list.
3. Verify that "VSS User Name", "VSS Command",
"VSS Project" and "SSDIR" textfields appeared
in the dialog. |
RESULT: The "Profile" page
of the wizard must contain all fields plus "Unix Shell" in
case of Windows 95/98/ME. "VSS Command", "VSS Project"
and "SSDIR" must be preset with default values. |
2.2 VSS connected
|
1. Setup "Working Directory"
to the directory you prepared e.g. D:\Tests\VSS\Work1.
2. Setup your name to "VSS User Name" textfield.
3. Make sure that "VSS Command" is set correctly with SS
binary.
4. Make sure that "SSDIR" contains directory with srcsafe.ini
file.
5. Eventually setup "Unix Shell" in case of Windows
95/98/ME system and push "Finish" button.
6. Give your password and push "OK" button. |
RESULT: "VSS D:\Tests\VSS\Work1"
filesystem must be mounted into explorer and status line must contain "Command
Refresh finished" message. |
3. Repository creation
Purpose: This
suite tests whether it is possible to upload source code into VSS
repository. It is essential
to start version control over new files in order to work with them
later on a daily basis.
Setup: The repository of VSS must be
completely empty.
| Test case # |
Description |
3.1 Create projects
|
1. Invoke VSS | Create Project action on "test
[Local]" node.
2. Type "For testing purpose." as reason into "Create
Project - test" dialog and push "OK" button.
3. Confirm the information message and repeat steps 1 and 2 for "another
[Local]" folder node. |
RESULT: Both projects must be created
successfully and appropriate nodes must have [Current]
status. |
3.2 Single file
addition
|
1. Invoke VSS | Add action on "A_File
[Local]" node.
2. Type "Generated A_File class." as reason into "Add
- A_File.java" dialog and push "OK" button.
3. Confirm the information message about successful addition. |
RESULT: The status of "A_File"
node must change to [Current]. |
3.3 Multiple file
addition
|
1. Select remaining [Local] files as one
multiselection using CTRL key.
2. Invoke VSS | Add
action on them.
3. Type "Auto-generated class file." as reason into "Add
- D_File.java..." dialog and push "OK" button.
4. Confirm all the information dialogs about successful addition. |
RESULT: The status of all remaining
nodes must change to [Current]. |
Purpose: This
suite tests the most often used commands of typical VSS user.
Setup: No preparation required.
| Test case # |
Description |
4.1 Checkout a file
|
1. Double click "A_File [Current]"
node. It will be opened into editor.
2. Right click "A_File [Current]" node in explorer.
3. Select VSS | Check Out
from the popup menu. |
RESULT: After a while the status of file
must change to "A_File [Current] (...)" where "..."
means your user name. Its editor tab must not indicate the file as
(read-only). |
4.2 Modify the file
|
1. Insert brand-new line somewhere into
the file.
2. Delete some other line but not directly next to the new line.
3. Modify another line but not directly next to the lines mentioned
above and Save the
file. |
RESULT: The file must change to "A_File
[Locally Modified] (...)". |
4.3 View differences
|
1. Invoke VSS | Diff on "A_File [Locally
Modified] (...)" node. |
| RESULT: All three differences must be
highlighted in a special window with both versions of the file. New
line is green, removed line is red and modified one is blue. |
4.4 Checkin the file
|
1. Invoke VSS | Check In on "A_File
[Locally Modified] (...)" node.
2. Setup "Three lines have changed." as "Change
Description" and push "OK" button. |
RESULT: The file must become read-only
and "A_File [Current]" again. |
4.5 Inspect the file
|
1. Invoke VSS | History on "A_File [Current]"
node.
2. Check that correct comment messages of both versions are printed in "Standard
Output" tab.
3. Invoke VSS | Properties
on "A_File [Current]" node. |
| RESULT: Output window must contain brief
information about the file. Make sure that given information is correct. |
4.6 Get a missing file
|
1. Invoke VSS | Get Latest Version on "A_File
[Current]" node.
2. Check "Make the Local Copy Writable" checkbox and push "OK"
button.
3. Delete the "A_File
[Current]" node.
4. Repeat step 1 on "A_File.java [Missing]" node once it
occurs and just push "OK" button. |
RESULT: Make sure the file was checked
out and recognized. It must have "A_File [Current]" status
and become read-only again. |
4.7 Give up a lock on
file
|
1. Invoke VSS | Check Out on "A_File
[Current]" node.
2. Invoke VSS | Undo Check Out
on "A_File [Current] (...)" node. |
RESULT: Make sure the file has "A_File
[Current]" status and became read-only again. |
Purpose: This
suite tests less often used commands and less typical workflows of VSS
user.
Setup: No preparation required.
| Test case # |
Description |
5.1 Remove a file
from repository
|
1. Invoke VSS | Remove on "D_File [Current]"
node.
2. Confirm the dialog informing user about successful removal of the
file. |
RESULT: The file must change to "D_File
[Local]". |
5.2 Put back a file
to repository
|
1. Invoke VSS | Recover on "D_File [Local]"
node.
2. Confirm the dialog informing user about successful recovery of the
file. |
RESULT: The file must change to "D_File
[Current]". |
| 5.3 Local refreshing |
1. Externally delete D_File.java
file.
2. Within 15 seconds invoke VSS
| Refresh on "D_File [Current]" node.
3. The file must immediately change to "D_File.java [Missing]".
4. Invoke VSS | Get Latest
Version on "D_File.java [Missing]" node.
5. Push "OK" button and repeat step 1.
6. Within 15 seconds invoke VSS
| Refresh on "another [Current]" node. |
RESULT: The file must immediately change
to "D_File.java [Missing]". |
| 5.4 Recursive checkout |
1. Invoke VSS | Check Out on test [Current]
node.
2. Uncheck "Check Out Recursively" and push "OK"
button.
3. Close the "Retrieving" dialog and output window once
it's done.
4. The "D_File.java" node must stay [Missing].
5. Repeat step 1 and push "OK" button directly. |
RESULT: Once "Retrieving..."
dialog has finished its work, the node must immediately change to "D_File
[Current] (...)". Also B_File and Formular
nodes must be [Current] (...). |
| 5.5 Recursive
refreshing |
1. Externally delete D_File.java
file.
2. Within 15 seconds invoke VSS
| Refresh Recursively on "test [Current]" node.
|
RESULT: Once "Retrieving..."
dialog has finished its work, the file must immediately change to "D_File.java
[Missing] (...)". |
| 5.6 Recursive get
latest version |
1. Invoke VSS | Get Latest Version on test
[Current] node.
2. Uncheck "Get Latest Version Recursively" and push "OK"
button.
3. Close the "Retrieving" dialog and output window once
it's done.
4. The "D_File.java" node must stay [Missing] (...).
5. Repeat step 1 and push "OK" button directly. |
RESULT: Once "Retrieving..."
dialog has finished its work, the node must immediately change to "D_File
[Current] (...)" and become read-only. |
| 5.7 Recursive undo
checkout |
1. Invoke VSS | Undo Check Out on test
[Current] node.
2. Push "OK" and close the "Retrieving"
dialog and output window once it's done.
3. The "D_File.java" node must stay [Current] (...).
4. Repeat step 1, check "Undo checkout recursively" and
push "OK" button. |
RESULT: Once "Retrieving..."
dialog has finished its work, all nodes must have only [Current]
status. |
| 5.8 Recursive checkin |
1. Invoke VSS | Check Out on test [Current]
node and push "OK".
2. Invoke VSS | Check In
on test [Current] node.
3. Uncheck "Check In Recursively" and push "OK"
button.
4. Close the "Retrieving" dialog and output window once
it's done.
5. The "D_File.java" node must stay [Current] (...).
6. Repeat step 2 and push "OK" button directly. |
RESULT: Once "Retrieving..."
dialog has finished its work, all nodes must have only [Current]
status. |
| 5.9 Recursive
inspection |
1. Invoke VSS | History on another
[Current] node.
2. Verify that output window contains history of all actions done in
that folder like removal or recovery of D_File.java.
3. Invoke VSS | Properties
on another [Current] node. |
RESULT: Verify that "Standard
Output" tab contains information concerning another
directory like number of files and its subprojects. |
| 5.10 Set password |
1. Create new command "Test"
with execution string cmd /x /c "echo ${PASSWORD}" and
turn on its "Display Output" property.
2. Invoke VSS | Set Password For
$/ command on the filesystem.
3. Type in "abcd" and push "OK" button.
4. Invoke Test
command on the filesystem. |
RESULT: Verify that there is "abcd"
printed in the "Standard Output" tab of output window. |
Purpose: This
suite tests other features like versioning explorer and VCS groups
support.
Setup: No preparation required.
| Test case # |
Description |
6.1 View old revision
|
1. Invoke Show Versions on "A_File
[Current]" node.
2. "A_File.java [Current]" node must be expanded in
special window and contain two revisions with proper comments.
3. Invoke Open on "1.0
Generated A_File class." node. |
| RESULT: The initial revision of A_File
must get opened into editor. |
6.2 Compare two
revisions
|
1. Invoke Diff on "1.0 Generated A_File
class." node.
2. Exactly the same window as in "4.3 View Differences"
test case must get opened into editor.
3. Multiselect both revisions and invoke Diff on them again. |
| RESULT: The same window with highlighted
differences must open again. |
6.3 Add file to VCS
group
|
1. Invoke Include in VCS Group | <Default Group>
on "A_File.java [Current]" node.
2. Invoke Windows | Versioning |
VCS Groups
from main menu.
3. Special window will show up. Expand "<Default Group>"
node. |
RESULT: There must be "A_File
[Current]" node under that group. |
6.4 Checkin from VCS
group
|
1. Invoke VSS | Check Out on "A_File.java
[Current]" node in "Versioning" window.
2. Switch to "Filesystems" tab of explorer, open that
file, modify it and Save
it.
3. Setup "Description" property of "<Default
Group>" node to "Checked in from VCS group.".
4. Invoke VSS | Check In
on "<Default Group>" node.
5. Make sure that "Check In - A_File.java" dialog contains
"Checked in from VCS group." comment and push "OK".
|
RESULT: A_File node must
change to [Current] state and there must be "3.0
Checked in from VCS group." node under "A_File.java
[Current]" node in "Versioning" window. |
6.5 Verify VCS group
|
1. Invoke Verify on "<Default Group>"
node.
2. Check "Remove Files From Group" on "Not Changed"
tab and push "Correct Group" button. |
RESULT: The "A_File [Current]"
node must disappear from "<Default Group>" group. |
Any comments and
suggestions please send to Jiri
Kovalsky.
