# End to End Testing of OneDrive Client for Linux

| Test Case Results |
|:------------------|
|[![E2E Testing - Personal Account](https://github.com/abraunegg/onedrive/actions/workflows/e2e-personal.yaml/badge.svg)](https://github.com/abraunegg/onedrive/blob/master/docs/end_to_end_testing.md)|
|[![E2E Testing - Personal Account: 15 Character driveId Check](https://github.com/abraunegg/onedrive/actions/workflows/e2e-personal-15char-check.yaml/badge.svg)](https://github.com/abraunegg/onedrive/blob/master/docs/end_to_end_testing.md)|
|[![E2E Testing - Personal Account: Shared Folders](https://github.com/abraunegg/onedrive/actions/workflows/e2e-personal-shared-folders.yaml/badge.svg)](https://github.com/abraunegg/onedrive/blob/master/docs/end_to_end_testing.md)|
|[![E2E Testing - Business Account](https://github.com/abraunegg/onedrive/actions/workflows/e2e-business.yaml/badge.svg)](https://github.com/abraunegg/onedrive/blob/master/docs/end_to_end_testing.md)|
|[![E2E Testing - Business Account: Shared Folders](https://github.com/abraunegg/onedrive/actions/workflows/e2e-business-shared-folders.yaml/badge.svg)](https://github.com/abraunegg/onedrive/blob/master/docs/end_to_end_testing.md)|
|[![E2E Testing - SharePoint Configuration](https://github.com/abraunegg/onedrive/actions/workflows/e2e-sharepoint.yaml/badge.svg)](https://github.com/abraunegg/onedrive/blob/master/docs/end_to_end_testing.md)|

This document describes the **end-to-end (E2E) automated testing framework** used to validate the behaviour of the OneDrive Client for Linux.

The test suite runs inside **GitHub Actions** and performs **real synchronisation operations against Microsoft OneDrive** using dedicated test accounts.

The objective of the test framework is to ensure that all client functionality continues to operate correctly across future changes to the application.

### Personal and Business Account Testing
Personal and Business end-to-end testing executes the full automated test suite against the default drive associated with the authenticated account, without explicitly specifying a `drive_id` in the client configuration. In this mode, the Microsoft Graph API implicitly resolves the user’s primary drive (personal OneDrive or business OneDrive root) and all drive enumeration, metadata retrieval, path traversal, upload, download, delete, and synchronisation operations are performed within that default context. As a result, the same comprehensive set of test cases validates client behaviour, configuration handling, and synchronisation correctness using the standard account-bound drive, ensuring expected operation without any explicit drive targeting or override.

Note: Personal Shared Folder testing and Business Shared Folder testing are performed separately because OneDrive shared folder shortcuts introduce different path resolution, metadata, drive discovery, shortcut anchoring, and filtering behaviour from standard account-root synchronisation.

### SharePoint Account Testing
SharePoint end-to-end testing uses the same complete automated test suite as Personal OneDrive and OneDrive for Business, but changes the target drive by supplying a `drive_id` value in the client configuration. This means the harness is not merely repeating the same account-type tests against the same default drive context; it is explicitly forcing the client to enumerate, access, and operate against a different Microsoft Graph drive object, resulting in different drive discovery, metadata enumeration, path traversal, upload, download, delete, and synchronisation API activity. By injecting `drive_id` into the test configuration, every existing test case is executed against a SharePoint document library context rather than a personal or business default OneDrive root, ensuring that the full suite validates client behaviour, configuration handling, and synchronisation correctness when operating against SharePoint-backed storage.

### Test Case Details

| Test&nbsp;Case | Description | Account&nbsp;Coverage | Test&nbsp;Details |
|:---------------|:------------|:----------------------|:------------------|
| 0001 | Basic Resync           |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| - validate that the E2E framework can invoke the client<br> - validate that the configured environment is sufficient to run a basic sync<br> - provide a simple baseline smoke test before more advanced E2E scenarios |
| 0002 | 'sync_list' Validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This validates sync_list as a policy-conformance test.<br><br>The test is considered successful when all observed sync operations involving the fixture tree match the active sync_list rules.<br><br>This test covers exclusions, inclusions, wildcard and globbing for paths and files. Specific 'sync_list' test coverage is as follows:<br>- Scenario SL-0001: root directory include with trailing slash<br>- Scenario SL-0002: root include without trailing slash<br>- Scenario SL-0003: non-root include by name<br>- Scenario SL-0004: include tree with nested exclusion<br>- Scenario SL-0005: included tree with hidden directory excluded<br>- Scenario SL-0006: file-specific include inside named directory<br>- Scenario SL-0007: rooted include of Programming tree<br>- Scenario SL-0008: exclude Android recursive build output and include Programming<br>- Scenario SL-0009: exclude Android recursive .cxx content and include Programming<br>- Scenario SL-0010: exclude Web recursive build output and include Programming<br>- Scenario SL-0011: exclude .gradle anywhere and include Programming<br>- Scenario SL-0012: exclude build/kotlin anywhere and include Programming<br>- Scenario SL-0013: exclude .venv and venv anywhere and include Programming<br>- Scenario SL-0014: exclude common cache and vendor directories and include Programming<br>- Scenario SL-0015: complex style Programming ruleset<br>- Scenario SL-0016: massive mixed rule set across Programming Documents and Work<br>- Scenario SL-0017: stress test kitchen sink rule set with broad include and targeted file include<br>- Scenario SL-0018: exact trailing slash configuration with cleanup validation<br>- Scenario SL-0019: no trailing slash workaround with cleanup validation<br>- Scenario SL-0020: focused trailing slash Projects regression for sibling path survival<br>- Scenario SL-0021: focused no trailing slash Projects regression for sibling path survival<br>- Scenario SL-0022: exact root-file include<br>- Scenario SL-0023: sync_root_files = true with rooted 'Projects' include<br>- Scenario SL-0024: cleanup regression with 'sync_root_files = true'<br>- Scenario SL-0025: prefix-collision safety for 'Projects/Code'<br>- Scenario SL-0026: mixed rooted subtree include plus exact root-file include<br>- Scenario SL-0027: wildcard directory include across similarly named Project Code folders<br>- Scenario SL-0028: globbing directory include for src directories across nested project depths<br>- Scenario SL-0029: wildcard directory include with deeper wildcard exclusion<br>- Scenario SL-0030: globbing directory include with recursive globbing exclusion<br>- Scenario SL-0031: normal directory include with deeper wildcard exclusion must not exclude ancestor<br>- Scenario SL-0032: normal directory include with deeper globbing exclusion must not exclude ancestor<br>- Scenario SL-0033: generic wildcard include with per-matched-container child exclusion<br>- Scenario SL-0034: generic globbing include traverses multiple seeded trees without premature pruning<br>- Scenario SL-0035: generic exact file include with sibling wildcard exclusion<br>- Scenario SL-0036: generic path with spaces using wildcard and globbing include<br>- Scenario SL-0037: generic cleanup_local_files with included root and excluded child subtree<br>- Scenario SL-0038: generic cleanup_local_files with wildcard include and excluded sibling container children<br>- Scenario SL-0039: generic sync_root_files override retains logical root files without entering unrelated fixture subtrees<br> |
| 0003 | Dry-run safety validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that running the client with `--dry-run` performs a full synchronisation analysis without making any changes locally or remotely. Files and directories are created in the test environment, the client is executed with `--dry-run`, and the test verifies that no filesystem or remote changes occur.|
| 0004 | Single-directory sync scope validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that the `--single-directory` option restricts synchronisation to the specified directory subtree. Only the nominated directory should be synchronised, while other directories outside the scope must remain untouched. |
| 0005 | Force-sync override validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that the `--force-sync` option overrides blocking conditions that would normally prevent synchronisation of a single-directory scope. The test confirms that forced synchronisation proceeds even when skip rules would otherwise block the operation. |
| 0006 | Download-only sync validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the behaviour of the `--download-only` option. Remote content is seeded in OneDrive and the client is executed in download-only mode. The test verifies that the remote data is correctly downloaded locally without performing any upload operations. |
| 0007 | Download-only cleanup validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the behaviour of `--cleanup-local-files` when used with `--download-only`. Local files that no longer exist remotely should be removed during synchronisation while valid remote content is preserved. |
| 0008 | Upload-only sync validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that `--upload-only` mode correctly uploads local files and directories to OneDrive. The test ensures that no download operations occur and that remote content reflects the locally created files. |
| 0009 | Upload-only remote preservation validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the behaviour of the `--no-remote-delete` option when used with `--upload-only` mode. The test confirms that remote files are not deleted even when they do not exist locally. |
| 0010 | Upload-only source removal validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the `--remove-source-files` option used with `--upload-only` mode. After files are successfully uploaded to OneDrive, the local source files should be automatically removed. |
| 0011 | Skip-file pattern validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that `skip_file` configuration patterns correctly exclude matching files from synchronisation. Files matching the configured patterns should not be uploaded or downloaded. |
| 0012 | Skip-directory rule validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the behaviour of the 'skip_dir' option and the 'skip_dir_strict_match' setting. The test confirms that directories matching the configured patterns are correctly excluded from synchronisation. |
| 0013 | Dotfile exclusion validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the 'skip_dotfiles' option. Files and directories beginning with a dot (`.`) should be excluded from synchronisation when this option is enabled. |
| 0014 | File size exclusion validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the 'skip_size' option. Files exceeding the configured size threshold should be excluded from synchronisation.|
| 0015 | Symlink exclusion validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the 'skip_symlinks' configuration option. Symbolic links present in the local filesystem should not be synchronised when this option is enabled. |
| 0016 | `.nosync` directory exclusion validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the 'check_nosync' feature. Directories containing a `.nosync` marker file should be excluded from synchronisation. |
| 0017 | `.nosync` mount protection validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the 'check_nomount' safeguard. When a `.nosync` marker exists in the mount point of the synchronisation directory, the client should abort synchronisation to prevent unintended operations.|
| 0018 | Recycle bin integration validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates integration with the FreeDesktop-compliant recycle bin. When files are deleted remotely, the client should move them into the configured recycle bin instead of permanently deleting them when the feature is enabled.|
| 0019 | Logging and runtime configuration validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that the client correctly writes logs to a configured 'log_dir' and that `--display-running-config` outputs the effective runtime configuration. |
| 0020 | Monitor mode real-time sync validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that when the client runs in `--monitor mode`, filesystem changes made while the process is running are automatically detected and synchronised without manually re-running the client. This validates inotify-based filesystem event handling under real-time event propagation conditions. |
| 0021 | Resumable upload recovery validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates resumable upload and download session behaviour. Large file transfers are intentionally interrupted using controlled transfer abort behaviour and then resumed during a subsequent client execution using the same client state. The test confirms that the transfer successfully completes without requiring a full resync. |
| 0022 | Local-first conflict resolution validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the 'local_first' configuration option. When a file conflict occurs between local and remote versions, the client should treat the local file as the authoritative source and update the remote version accordingly. |
| 0023 | Bypass data preservation validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the behaviour of the 'bypass_data_preservation' option. When enabled, the client should suppress the creation of safe-backup files during conflict resolution and allow remote content to overwrite local changes. |
| 0024 | Big delete safeguard validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the 'classify_as_big_delete' protection mechanism. When a large number of items are deleted locally, the client should halt synchronisation and emit a warning. The deletion should only proceed after the user explicitly acknowledges the action using `--force`. This also validates consistent safeguard behaviour across account types where API timing or enumeration differences may occur. |
| 0025 | Invalid character filename validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that invalid filename characters are blocked while valid sibling files still synchronise |
| 0026 | Reserved device name validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that reserved Windows device names are blocked while valid lookalike names still synchronise |
| 0027 | Whitespace and trailing dot validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that trailing whitespace and trailing dot names are blocked while valid sibling files still synchronise |
| 0028 | Control character and non-UTF8 filename validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that control characters and non-UTF8 filenames are safely skipped without client crash while valid sibling files still synchronise |
| 0029 | Upload-only + Local First sync validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that `--local-first --upload-only` uploads local content without rewriting local file timestamps from Microsoft API response data |
| 0030 | Local rename propagation validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that renaming a local file is correctly propagated to remote state |
| 0031 | Local directory rename propagation validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that renaming a local directory tree is correctly propagated to remote state |
| 0032 | Remote file rename reconciliation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that a stale local client correctly reconciles a remote-side file rename without leaving stale local leftovers |
| 0033 | remote directory rename reconciliation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that a second client with existing local and database state correctly reconciles a remote directory rename propagated by another synchronising client |
| 0034 | Local move between directories validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that moving a local file from one directory to another is correctly propagated to remote state |
| 0035 | Remote move between directories reconciliation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that a stale local client correctly reconciles a remote-side file move between directories without leaving stale local file leftovers |
| 0036 | Overwrite / replace existing file content validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that replacing the contents of an existing local file with the same name correctly updates remote content without leaving stale content or metadata confusion |
| 0037 | mtime-only local change handling |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that mtime-only local file changes across direct upload, automatic session upload for files larger than 4 MiB, and forced session upload behaviour without changing file content |
| 0038 | Delete and recreate with same name validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that deleting a file, syncing that deletion, then recreating a different file with the same name correctly results in the final remote and local state without stale item-id or state database issues |
| 0039 | Empty directory handling |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that creation, sync, verification, and cleanup behaviour for empty directories, including nested empty directories, to ensure directory-only state is created and removed correctly |
| 0040 | Nested tree rename and delete stress validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that a combined nested-tree mutation scenario involving multiple renames, one deletion, and one new file creation before a single sync, ensuring the final remote and fresh-download state is correct with no stale paths left behind |
| 0041 | Monitor mode local create upload |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates starting --monitor, create a local file, and validate it uploads without restarting the client |
| 0042 | Monitor mode local modify upload |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates modifying an existing local file under --monitor and validate the update propagates |
| 0043 | Monitor mode local delete propagation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates deleting a local file under --monitor and validate the remote delete occurs as expected |
| 0044 | Monitor mode local rename propagation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates renaming a local file while --monitor is active and validates correct behaviour |
| 0045 | Monitor mode local directory create propagation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates creating a new local directory and child file under --monitor and validate the remote state |
| 0046 | Monitor mode local directory rename propagation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates renaming a populated local directory while --monitor is active and validate the final remote state |
| 0047 | Monitor mode local directory delete propagation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates deleting a populated local directory tree under --monitor and validate the remote delete |
| 0048 | Monitor mode burst local file creates |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test rapidly create multiple local files under --monitor and validate they all upload correctly |
| 0049 | Monitor mode mixed burst operations |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test performs create, modify, delete, and rename operations in one burst under --monitor and validate the final state |
| 0050 | Monitor mode nested file create inside new directory |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test creates a nested directory tree and deep file under --monitor and validate the remote state |
| 0051 | Monitor mode mtime-only local change handling |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test touches an existing local file under --monitor without changing content and validate that no new upload occurs |
| 0052 | Monitor mode large file create session upload |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test creates a large file under --monitor and validate session upload behaviour and remote integrity |
| 0053 | Monitor mode rename then modify |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test renames a file and then modify the renamed file under --monitor and validate the final remote state |
| 0054 | Monitor mode atomic-save editor replace workflow |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test replaces an existing file via temp-file save and atomic rename under --monitor and validate the final remote state |
| 0055 | Upload-only remove-source-folders |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that remove_source_folders removes empty local directory structure after upload-only succeeds |
| 0056 | Monitor mode create then delete quickly |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test creates and delete a local file quickly under --monitor and validate stability and final remote state |
| 0057 | Recycle bin delete behaviour validation | -&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates `use_recycle_bin` behaviour for online-origin deletes and local-origin delete propagation. It confirms that remote-originated deletes can be moved to the local recycle bin when configured, while local-originated deletes are correctly propagated to OneDrive as delete operations. |
| 0058 | Monitor download-only cleanup cadence |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates `monitor_authoritative_sync` behaviour when the client is running in `--monitor --download-only` mode with `--cleanup-local-files`. It confirms that authoritative cleanup is controlled by the configured monitor policy and distinguishes authoritative cleanup from normal Microsoft Graph `/delta` processing.<br><br>Specific coverage is as follows:<br>- Scenario MSIGNAL: `monitor_authoritative_sync = "monitor_and_signal"` validates that an authoritative cleanup pass is performed and DB-known stale local content is removed<br>- Scenario MINTERVAL: `monitor_authoritative_sync = "monitor_interval"` validates that authoritative cleanup occurs during monitor interval processing<br>- Scenario MFULLSCAN: `monitor_authoritative_sync = "monitor_fullscan_frequency"` validates that the first monitor pass uses native `/delta` processing and defers authoritative cleanup until the configured full-scan cadence<br>- Scenario NOCLEANUP: validates that without `--cleanup-local-files`, local-only stale content is retained<br><br>The test uses debug-level monitor output to validate the active policy path, because remote tombstone handling can remove files independently of authoritative cleanup and may vary across Personal, Business, and SharePoint drive contexts. |
| 0059 | WebSocket remote upload notification |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates near-real-time Microsoft Graph WebSocket notification handling by running one client in `--monitor` mode with an isolated `--confdir` and sync directory, then using a second isolated client running `--sync --upload-only` to upload a new file. The monitor client must receive the WebSocket signal, process the resulting `/delta`, and download the remotely uploaded file without relying on the normal `monitor_interval` cadence. |
| 0060 | Monitor mode local move reconciliation without delete/re-upload |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that moving already synchronised local files and populated directory trees while running under `--monitor --verbose` is correctly propagated as remote move operations rather than delete and re-upload behaviour. The test performs local inotify-triggered move operations while the client is actively monitoring the filesystem, validates that remote state is updated to the new path location, and confirms through debug log analysis that stale descendant delete operations and unnecessary re-upload activity do not occur during reconciliation. |
| 0061 | Remote move into skip_dir reconciliation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that when a second synchronising endpoint running in `--monitor` mode moves previously synchronised files from a normal synced path into a destination excluded via `skip_dir`, the original Linux client correctly reconciles the remote move using its existing local database state. The test confirms that stale local source files are removed from the original synced location, skipped destination content is not downloaded locally, unrelated sibling files remain preserved, and the moved files remain correctly online in the skipped destination path. |
| 0062 | Transfer Metrics validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates that upload and download transfer metric reporting is generated correctly when running with `--verbose --verbose`. The test confirms that transfer statistics are emitted for both upload and download operations, validates reported file size accuracy, verifies the presence of separate network transfer and end-to-end processing duration fields, and ensures transfer speed reporting is correctly formatted using Mbps units. |
| 0063 | Local parent path rename during active download |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates client behaviour when a local parent directory is renamed while a file download is actively in progress during a normal synchronisation operation using `local_first = true`. The test confirms that local filesystem races are correctly detected and reported, that download failures are handled safely without client instability or database corruption, and that local filesystem failures are not incorrectly reported as Microsoft Graph API HTTP status code errors.|
| 0064 | Local authoritative remote mirror validation |-&nbsp;Personal<br>-&nbsp;Business<br>-&nbsp;SharePoint| This test validates the `mirror_local_state` configuration option when used with `local_first = true`. The test confirms that during a full `--resync --resync-auth` operation, remote-only files and directories that no longer exist locally are removed from Microsoft OneDrive rather than being downloaded, ensuring the remote state becomes an exact mirror of the local filesystem. |


### OneDrive Personal Shared Folder Testing
Personal Shared Folder end-to-end testing validates client behaviour when synchronising content accessed via OneDrive shared folder shortcuts.

Unlike standard directory structures, shared folders are represented through shortcut-style access to content that may be backed by different OneDrive drive items. This introduces unique behaviour in path resolution, metadata handling, shortcut anchoring, and `sync_list` evaluation.

These tests ensure that:
- shared folder shortcuts are correctly discovered and traversed
- preserved shared folder topology is pulled down without creating ghost folders
- linked shared folder content is synchronised without corrupting local path structure
- `sync_list` rules correctly apply across shared folder shortcut boundaries
- renamed, nested, and path-with-spaces shared folders remain anchored correctly
- wildcard, globbing, inclusion, exclusion, and cleanup scenarios behave correctly for shared folder paths
- safe test mutations do not unintentionally modify preserved shared folder fixture content

### Personal Shared Folder Test Case Details

| Test&nbsp;Case | Description | Account&nbsp;Coverage | Test&nbsp;Details |
|:---------------|:------------|:----------------------|:------------------|
| 0001 | Personal shared folders clean sync pull down | - Personal | This test validates that `--sync --verbose` pulls down the preserved Personal Account shared folder topology without creating ghost folders. It confirms that shared folder shortcuts are discovered, traversed, and materialised locally using the expected path structure. |
| 0002 | Personal shared folders clean monitor pull down | - Personal | This test validates that `--monitor --verbose` pulls down the preserved Personal Account shared folder topology without creating ghost folders. It confirms that monitor mode can initialise shared folder content correctly and remain stable while filesystem monitoring is active. |
| 0003 | Personal shared folders `sync_list` validation | - Personal | This validates `sync_list` include and exclude behaviour across the preserved Personal Account shared folder topology without creating ghost folders.<br><br>The test is considered successful when all observed sync operations involving the shared folder fixture topology match the active `sync_list` rules, including shortcut path anchoring and resolved shared folder paths.<br><br>Specific Personal Shared Folder `sync_list` coverage is as follows:<br>- Scenario SL-0001: rooted include of one shared folder tree with trailing slash<br>- Scenario SL-0002: rooted include of one shared folder tree without trailing slash<br>- Scenario SL-0003: rooted include of deep shared folder path<br>- Scenario SL-0004: include shared folder tree with nested exclusion<br>- Scenario SL-0005: file-specific include inside a shared folder<br>- Scenario SL-0006: multiple file-specific includes within one shared folder<br>- Scenario SL-0007: include nested tree shared folder and exclude sibling shared folder trees<br>- Scenario SL-0008: mixed includes across minimal renamed and deep shared folders<br>- Scenario SL-0009: include shared folder path containing spaces<br>- Scenario SL-0010: multiple explicit shared-folder shortcut includes only<br>- Scenario SL-0011: safe tracked mutation inside an existing shared-folder directory<br>- Scenario SL-0012: issue 3643 explicit Family pictures shared-folder includes only<br>- Scenario SL-0013: wildcard shared-folder directory include across WIDE_SET shortcuts<br>- Scenario SL-0014: globbing include for a file below a shared-folder directory tree<br>- Scenario SL-0015: normal shared-folder include with deeper wildcard exclusion<br>- Scenario SL-0016: normal shared-folder include with deeper globbing exclusion<br>- Scenario SL-0017: wildcard shared-folder include with wildcard exclusion of one matched shortcut's children<br>- Scenario SL-0018: wildcard shared-folder include with globbing exclusion of one matched file<br>- Scenario SL-0019: shared-folder shortcut name collision with different per-shortcut exclusions<br>- Scenario SL-0020: shared-folder exact file include with sibling wildcard exclusion<br>- Scenario SL-0021: shared-folder path with spaces using wildcard and globbing include<br>- Scenario SL-0022: renamed shared folder include remains anchored without ghost sibling creation<br>- Scenario SL-0023: shared-folder globbing include across TREE shortcut variants<br>- Scenario SL-0024: cleanup_local_files removes local-only stale file under included shared-folder parent |


### OneDrive Business Shared Folder Testing
Business Shared Folder end-to-end testing validates client behaviour when synchronising content accessed via OneDrive for Business shared folder shortcuts.

Unlike standard Business account-root synchronisation, shared folders are represented through shortcut-style access to content that may be backed by different OneDrive drive identifiers and remote document library contexts. This introduces unique behaviour in drive discovery, path resolution, metadata handling, shortcut anchoring, and `sync_list` evaluation.

These tests ensure that:
- Business shared folder shortcuts are correctly discovered and traversed
- preserved Business shared folder topology is pulled down without creating ghost folders
- linked shared folder content is synchronised without corrupting local path structure
- `sync_list` rules correctly apply across Business shared folder shortcut boundaries
- wildcard, globbing, inclusion, exclusion, and cleanup scenarios behave correctly for Business shared folder paths
- deep path traversal behaves correctly across different shared folder drive contexts
- similarly named shared folder trees remain correctly isolated during wildcard and globbing evaluation
- safe test mutations do not unintentionally modify preserved Business shared folder fixture content

### Business Shared Folder Test Case Details

| Test&nbsp;Case | Description | Account&nbsp;Coverage | Test&nbsp;Details |
|:---------------|:------------|:----------------------|:------------------|
| 0001 | Business shared folders clean sync pull down | - Business | This test validates that `--sync --verbose` pulls down the preserved Business Account shared folder topology without creating ghost folders. It confirms that Business shared folder shortcuts are discovered, traversed, and materialised locally using the expected path structure. |
| 0002 | Business shared folders clean monitor pull down | - Business | This test validates that `--monitor --verbose` pulls down the preserved Business Account shared folder topology without creating ghost folders. It confirms that monitor mode can initialise Business shared folder content correctly and remain stable while filesystem monitoring is active. |
| 0003 | Business shared folders `sync_list` validation | - Business | This validates `sync_list` include and exclude behaviour across the preserved Business Account shared folder topology without creating ghost folders.<br><br>The test is considered successful when all observed sync operations involving the shared folder fixture topology match the active `sync_list` rules, including shortcut path anchoring, resolved shared folder paths, SharePoint-backed shared folders, user-owned shared folders, renamed shared-folder shortcuts, root-level shared-folder shortcuts, and different Business shared-folder drive contexts.<br><br>Specific Business Shared Folder `sync_list` coverage is as follows:<br>- Scenario SL-0001: rooted include of one Business shared folder tree with trailing slash<br>- Scenario SL-0002: rooted include of one Business shared folder tree without trailing slash<br>- Scenario SL-0003: rooted include of deep Business shared folder path<br>- Scenario SL-0004: include Business shared folder tree with nested exclusion<br>- Scenario SL-0005: file-specific include inside a Business shared folder<br>- Scenario SL-0006: multiple file-specific includes within one Business shared folder<br>- Scenario SL-0007: include nested Business shared folder tree and exclude sibling shared folder trees<br>- Scenario SL-0008: mixed includes across minimal renamed and deep Business shared folders<br>- Scenario SL-0009: include Business shared folder path containing spaces<br>- Scenario SL-0010: multiple explicit Business shared-folder shortcut includes only<br>- Scenario SL-0011: safe tracked mutation inside an existing Business shared-folder directory<br>- Scenario SL-0012: wildcard Business shared-folder directory include across WIDE_SET trees<br>- Scenario SL-0013: globbing include for a file below a Business shared-folder directory tree<br>- Scenario SL-0014: normal Business shared-folder include with deeper wildcard exclusion<br>- Scenario SL-0015: normal Business shared-folder include with deeper globbing exclusion<br>- Scenario SL-0016: wildcard Business shared-folder include with wildcard exclusion of one matched shortcut's children<br>- Scenario SL-0017: wildcard Business shared-folder include with globbing exclusion of one matched file<br>- Scenario SL-0018: Business shared-folder exact file include with sibling wildcard exclusion<br>- Scenario SL-0019: Business shared-folder path with spaces using wildcard and globbing include<br>- Scenario SL-0020: renamed Business shared folder include remains anchored without ghost sibling creation<br>- Scenario SL-0021: Business shared-folder globbing include across TREE shortcut variants<br>- Scenario SL-0022: cleanup_local_files removes local-only stale file under included Business shared-folder parent<br>- Scenario SL-0023: deep Business shared-folder globbing include with retained sibling empty directory structure<br>- Scenario SL-0024: explicit Business shared-folder subtree include across different shared-folder drive contexts<br>- Scenario SL-0025: exact file include across multiple Business shared-folder roots<br>- Scenario SL-0026: explicit subtree include across multiple Business shared-folder roots<br>- Scenario SL-0027: mixed Business shared-folder include and exclusion behaviour across different shortcut-backed drive identifiers<br>- Scenario SL-0028: SharePoint-backed shared-folder root include from non-default drive context<br>- Scenario SL-0029: SharePoint-backed deep shared-folder include retains correct ancestor path anchoring<br>- Scenario SL-0030: user-owned shared-folder root include outside default Data container<br>- Scenario SL-0031: renamed shared-folder shortcut remains isolated during wildcard traversal<br>- Scenario SL-0032: apostrophe-containing shared-folder path include and exclusion handling<br>- Scenario SL-0033: root-level and Data-level shared-folder wildcard traversal across mixed SharePoint and user-owned sources<br>- Scenario SL-0034: mixed SharePoint-backed and user-owned shared-folder exact file include validation across different remote drive identifiers |
| 0004 | Business shared files clean sync pull down | - Business | This test validates that `--sync --verbose --sync-shared-files` correctly enumerates and materialises OneDrive Business Shared Files into the Files Shared With Me local topology, preserving per-user grouping, file versus folder classification, and mixed shared-owner handling using the Microsoft Graph Search API replacement for the deprecated sharedWithMe endpoint. |
| 0005 | SharePoint library enumeration while monitor is running | - Business | This test validates that `--get-sharepoint-drive-id '*'` is treated as a no-sync operation and can be executed successfully using the exact same configuration directory, state database, and authentication context while another client instance is actively running in `--monitor` mode. The test confirms that SharePoint library discovery and enumeration continue to function correctly without triggering active-client detection, database-lock failures, or other concurrency restrictions intended only for synchronisation operations. |

### Contributing Additional Test Cases

While this end-to-end test suite provides broad and comprehensive coverage of the OneDrive Client for Linux, it is not exhaustive. Real-world usage continues to surface new edge cases, behaviours, and scenarios that may not yet be represented here. 

If you identify a gap in coverage, encounter a scenario that is not currently validated, or believe an existing test case could be improved, contributions are strongly encouraged. Please feel free to raise a discussion outlining the scenario, or ideally develop and submit a new test case via a pull request following the existing test framework structure. 

Community contributions play a critical role in strengthening the reliability and robustness of the client, and all well-defined additions are welcomed.
