Compartir a través de

Test Office for the web integration

  • Artículo

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

WOPI Validator tests

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

  • HostFrameIntegration (ValidLanguagePlaceholderValues might be skipped if the host isn't 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)

Important

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

Tip

Hosts aren't required to support RenameFile, PutRelativeFile or use proof key validation. However, hosts that 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

Co-authoring support is a major boon to users, but it's 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.

Important

The Office for the web applications have unique behavior with respect to co-authoring. So, it's 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 (as in, co-authoring doesn't occur), it likely means your WOPI file IDs aren't consistent. See file ID for more information.

  2. If one of the users is kicked out of the session while editing, 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 aren't user-owned. For more information, see Lock.

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 is immediately downloaded. This URL should not direct the user to some separate UI to download the file.

Rename

If you support renaming documents within Office for the web (as in, 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're displaying the document name in the browser window and tab using the HTML title tag, you should check that the document name is updated after the file is renamed. If it's not, check that you're 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 Microsoft Cloud Storage Partner Program Integration Terms.