## Editing Files

Since:
Last Modified: $Date: 2007/05/18 13:54:37 $

These tests are to sanity check editors behavior relating to calling validateEdit. The tests will try to cover all cases where files are changed by the validateEdit handler and changes are made to the read-only bit.

These test cases outline the expected behavior of single file editors in terms of calling validateEdit and handling of error conditions. All scenarios assume that a repository provider is mapped to a project and has created a sandbox with files that are marked read-only.

The org.eclipse.team.example.filesystem plugin is a repository provider that simulates a pessimistic workflow. You can use it to run these tests and validate (no pun intended) your validateEdit editor support. To use the pessimistic provider, share a project with the repository provider called "File System Pessimistic Example" and then you can add to control the files and checkin/checkout will toggle the read-only bit and touch the file. You can change the behavior of the validateEdit call via the pessimistic preference page. For example, you can force the operation to fail and update contents of the file when checked out.

These tests should be run against the following combinations of tools:

- Different repository providers
- Single file editors (java, text)
- Multiple file editors (manifest editor, ...)

### S1: Repository provider enabled and files are readable

1. Open a file that is not marked read-only in a project configured with a repository provider.
2. Start editing the file, validate edit should not be called.

### S2: Validate edit called on first edit

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit returns OK, the users edit is accepted and shows up in the editor, and the file can be edited normally.
4. The user saves the file, and then can continue editing without validateEdit being called.

### S2b: Validate edit canceled

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit is canceled, the users edit is not accepted and the file cannot be edited.
4. The user should still be able to browse the contents of the file and trying to edit it again

### S2b: Validate edit fails with an error

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit is canceled, the users edit is not accepted and the file cannot be edited. User should be shown the error returned from the validateEdit provider.
4. The user should still be able to browse the contents of the file and trying to edit it again

### S3: Validate edit called on subsequent edits if file changes state

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit returns OK, the user's edit is accepted and the file can be edited normally.
4. The user saves the file, and then can continue editing without validateEdit being called.
5. The user saves the file and then checks in the file while the editor is still open.
6. After the checkin completes the user continues editing the file.
7. Validate edit should be called again.

### S4: Validate edit not called after contents changed

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit returns OK, the user's edit is accepted and the file can be edited normally.
4. The user saves the file, and then can continue editing without validateEdit being called.
5. The user saves the file and keeps the editor opened.
6. The user then un-checks out the file and new file contents are retrieved from the server.
7. The new file contents are loaded into the editor and validateEdit is not called.

### S5: Validate edit changes file contents editor not-dirty

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit returns OK and brings in new content from the server.
4. The new content is loaded automatically because the editor isn't dirty yet.

### S6: Validate edit changes file contents editor dirty

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit returns OK and the file on disk doesn't change.
4. The user continues editing the file and then checks it in.
5. The editor remains open and dirty, the user continues editing.
6. validateEdit is called because the file is now read-only and returns OK and brings in new content from the server.
7. The editor detects the timestamp change and prompts about the conflict and provides options to the user.
8. After the user selects his option and the user continues editing, the editor will call validateEdit.

### S7: Read-only editors refreshing on checkout

1. Open a file that has been checked out as read-only from a repository provider.
2. Checkout the file that brings in new content from the server.
3. The editor should update with the new content from the server.

### S8: validate called on editor save

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit returns OK and the file on disk doesn't change.
4. The editor remains open and dirty, the user continues editing.
5. The user checks-n the file and then closes the editor.
6. The user is prompted to save the file, then validate edit is called, and the file is checked-out then saved.

### S9: validate called on editor save with new contents

1. Open a file that has been checked out as read-only from a repository provider.
2. Start editing the file, validateEdit should be called.
3. validateEdit returns OK and the file on disk doesn't change.
4. The editor remains open and dirty, the user continues editing.
5. The user checks-n the file and then closes the editor.
6. The user is prompted to save the file, then validate edit is called, and the file is checked-out then saved.