VSS Profile Test Specification for Generic VCS Module
Author: Jiri Kovalsky
Version: 1.0
Last update: Tue July 4 13:08:31 CET 2002
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.
2. Mount VSS filesystem
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 suitable for your operating system.
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 VSS 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]. |
4. Regular development
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. |
5. Additional commands
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. |
6. Additional features
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 Versioning Explorer 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 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.
