Testing Office for the web integration

Before starting the Launch process, you should do the following testing on your integration.

WOPI validator tests

All of the automated tests in the following categories must be passing in the WOPI validator:

  • HostFrameIntegration (ValidLanguagePlaceholderValues may be skipped if the host is not using the UI_LLCC or DC_LLCC placeholder values)

  • BaseWopiViewing

  • CheckFileInfoSchema

  • EditFlows

  • Locks

  • PutRelativeFile or PutRelativeFileUnsupported

  • RenameFileIfCreateChildFileIsNotSupported or RenameFileIfCreateChildFileIsSupported (applicable only if the host supports RenameFile)

  • FileVersion

  • PutUserInfo (applicable only if the host supports PutUserInfo)

  • ProofKeys (applicable only for hosts implementing proof key validation)


All of the applicable tests listed above must pass in order to go to production. We do not make exceptions to this requirement.


Hosts are not required to support RenameFile, PutRelativeFile or use proof key validation. However, hosts that do support these operations, or use application features that rely on them, those test groups must be passing.

For example, binary file conversion requires the PutRelativeFile operation be implemented, so hosts that support conversion must also pass the PutRelativeFile tests.

Office for the web feature verification

Many Office for the web features rely on a host’s WOPI implementation. You should test the following features to help ensure your WOPI implementation is correct and that the Office for the web integration is well-executed.


Co-authoring support is a major boon to users, but it is also used to verify your implementation of file IDs and lock-related WOPI operations. For this reason, multi-user co-authoring must be testable using the test accounts provided.


The Office for the web applications each have unique behavior with respect to co-authoring. Thus it is critical to test co-authoring in all three applications.

To check that co-authoring behaves as expected, you’ll need at least two different user accounts. Then, follow these steps:

  1. As User A, share a document with User B.

  2. Open the document in edit mode as User A.

  3. Open that same document in edit mode as User B.

  4. Check that both instances of the Office for the web application are participating in the co-authoring session.

  5. Make edits to the document as both users and ensure that both instances of the application remain connected to the co-authoring session.

  6. After making some edits, leave the session and verify that the saved file contains the edits made by both User A and User B.

Common issues

  1. If the users remain in different sessions (i.e. co-authoring does not occur) then it likely means your WOPI file IDs are not consistent. See file ID for more information.

  2. If one of the users is ‘kicked out’ of the session while editing, then it likely means that you’re rejecting lock-related requests that come from a different user than the one who originally took the lock. WOPI locks are not user-owned. See Lock for more information.

Single-user co-authoring

While the typical co-authoring scenario is two or more users collaborating on a single document in real-time, the feature also provides other benefits as outlined in Benefits from co-authoring support.

To check that single-user co-authoring behaves as expected:

  1. Open a document in edit mode.

  2. Open a document in edit mode using the same user account originally used, but in a different browser.

  3. Check that both instances of the Office for the web application are participating in the co-authoring session.

Downloaded files should have most recent document changes

If you are providing a DownloadUrl, you should ensure that a file downloaded using the Office for the web Download a Copy buttons contain the most recent edits. To test this:

  1. Open a document in edit mode.

  2. Make an edit to the document and wait for the Saved to <HostName> text to display.

  3. Click the File ‣ Save As ‣ Download a Copy button.

  4. Check that the downloaded file has the most recent edits you made to the document.

Download a Copy should not re-direct

As describe in DownloadUrl, Office for the web expects that when directing users to the DownloadUrl, the file will be immediately downloaded. This URL should not direct the user to some separate UI to download the file.


If you support renaming documents within Office for the web (i.e. SupportsRename is true), you should check that the rename operation behaves as expected. To test this:

  1. Open a document in edit mode.

  2. Click on the document name in the top title bar.

  3. Rename the document.

  4. Exit the Office for the web application and check that the file was renamed.

If you are displaying the document name in the browser window/tab using the HTML title tag, you should check that the document name is updated after the file is renamed. If it is not, check that you are properly handling the File_Rename PostMessage.

Save As in Excel for the web

Excel for the web supports saving an open document as a new copy of that document using the File ‣ Save As ‣ Save As button. This feature uses the PutRelativeFile WOPI operation. You should test that this feature works as expected.

UI integration

Ensure you follow the UI guidelines as well as the terms of the Cloud Storage Partner Program contract.