Manual tests

Release Tests

Tracking a Package

1. Create a new category for the new package in the System Browser. Add a new class in it. Add a method to it.
2. Create an empty folder in the filesystem.
3. In the Git Browser, right click in the Projects list and choose 'Add project'. You are prompted to enter the new project's name.
4. Enter 'releasetest1' as the new project's name and click 'accept'. Another dialog appears, prompting to select a folder.
5. Choose the empty folder created previously, and click 'ok'. The new project should show up in the project list in the Git Browser.
6. Right-click on the new project releasetest1. Choose 'Start tracking packages'. A dialog prompting for a selection of categories opens.
7. Select the newly created category and click accept. Another dialog appears, prompting to select a folder. The root of the folder tree is the previously selected project location, the empty folder you created previously.
8. Choose the root folder in the dialog and click 'ok'. No more dialogs appear.
9. In the Git Browser, click 'Commit' while the project 'releasetest1' is selected. A window opens which allows you to view the to-be-committed changes and to enter the commit message. The tree of to-be-committed changes lists your package name, followed by '.package' as a top node.
10. Expand all nodes in the tree of changes. Then enter a message and click 'Commit'. A new commit is created. It appears in the list of commits in the Git Browser while the project 'releasetest1' is selected. Its message equals the message you have previously entered. The list of objects in the Git Browser includes an item with your package's name, followed by '.package'.

Different ways of assigning a path to a package

1. Add the package in the root folder. A subfolder <root>/PackageName.package should be created after the package was first saved.
2. Add the package in a subfolder that is not named like the package. Another subfolder inside the chosen subfolder should be created, named <chosenSubfolder>/PackageName.package after the package was first saved.
3. Add the package in a subfolder that is already named like the package: 'PackageName.package'. The package will be put into the selected folder, no intermediary folders will be added.

In each case, the path of the package should be stable after the first save of the package. Subsequent saves should show the correct changes between the already saved package version and the currently loaded edition.

Clone an existing Squeak project that uses Squot from GitHub

How about https://github.com/hpi-swa-teaching/Gana.git?

1. In the Git Browser, right-click on the projects list and choose 'Clone project'.
2. Enter the URL of the repository at GitHub. Choose a local folder to store the git repository in.
3. Checkout tip commit from the master branch.

Git Browser

Tracking a Workspace

1. Create a new working copy (in the Projects list) called test1. It should show up in the project list in the Git Browser.
2. Explore the SquotWorkingCopy via the popup menu of test1. An ObjectExplorer opens on the test1 working copy.
3. Open a new workspace. This will be the tracked object. Create some formatted text in it. Accept its contents (Cmd-s). Inspect the model of the Workspace SystemWindow (e.g., by yellow-clicking on the title bar, inspect model). The opened inspector should show the entered text in the contents variable.
4. Open another workspace. Change the working copy ObjectExplorer to an Inspector via the inspect button in the lower right corner. Drag self from that inspector to the new workspace. Then drag self from the inspector of the to-be-tracked workspace into the new workspace. The new workspace should now include two variables that refer to the dropped objects.
5. Edit the text of the new workspace to be something like: squotWorkingCopy1455685 add: workspace1686309 at: 'workspace'. Do it. No error should be signalled. The tracked workspace appears in the working copy's store. You can check this with the inspector on the working copy, which you may also change back into an ObjectExplorer. Leave this workspace open for later steps.
6. With the test1 project selected, click the Commit button in the Git Browser. The "Select changes and message for the new version" dialog should appear. It contains a single item in the tree on the left side, which is labelled "workspace".
7. Click on the "workspace" item. No error should be signalled. The text field on the right side of the window should show something about adding that workspace.
8. Enter a commit log message and click Commit. The commit succeeds and appears in the versions list at the top of the Git Browser. With that version selected, an entry "workspace" appears in the object list in the lower-right corner of the Git Browser.
9. Edit the text in the tracked workspace and accept the changes. Then click Commit again in the Git Browser. The select changes window appears again.
10. Click the workspace tree item in the change selection window. To its right, some text about reassigning the contents variable appears.
11. Enter a commit log message and click Commit. The commit succeeds and appears in the versions list at the top of the Git Browser.
12. In the popup menu of the first created commit, click Checkout objects. The "Select changes to load" window appears.
13. Accept the changes as they are. The contents of the tracked workspace should change back to appear like it was when the first commit was created. If the visible text does not change, pretend to cancel (Cmd-l) changes in the workspace. The text from the first version should now appear.
14. Checkout the workspace from the second (newer) version similar to the previous steps. The workspace contents should change to be like when creating the second commit.
15. Close the tracked workspace and its inspector. In the other workspace (where you added the tracked workspace to the working copy), enter something like: squotWorkingCopy1455685 remove: workspace1686309 and do it. No error should be signalled.
16. Click Commit in the Git Browser again. The select changes window appears. It contains the "workspace" tree item as before.
17. Click on the "workspace" tree item. The text to the right should show something about removing the workspace.
18. Enter a commit log message and click Commit. The commit succeeds and appears in the Git Browser's version list.
19. Select the latest version in which the workspace has been removed. The objects list in the lower-right corner of the Git Browser should not contain the "workspace" entry any more.
20. In the popup menu of the first version that added the workspace, click Checkout objects. The select changes window appears with the workspace in the tree.
21. Accept the changes. No error is signalled. The store of the working copy should contain the workspace again.
22. In the other workspace, enter something like: workspace1686309 openLabel: 'Workspace' and do it. The tracked workspace should appear on the screen again, like it was saved in the first commit.
23. Close the tracked workspace. Checkout the latest commit, in which the workspace has been removed. No errors should be signalled. The workspace has disappeared again from the working copy's store.

Future

Clone an existing Squeak project that does NOT use Squot from GitHub