Mattermost Logo
We're hiring!
Edit on GitHub

Guide for Writing E2E Tests at Mattermost

Before writing a script, ensure that it has a corresponding test case in Zephyr. All test cases may be found in this link. If test case is not available, feel free to prompt the QA team who will either search from an existing Zephyr entry or if it’s a new one, it will be created for you.

  1. Create a test file based on folder and file structure.

  2. Include Zephyr identification (ID) and title in the test description, following the format of it('[Zephyr_id] [title]') or it('[Zephyr_id]_[step] [title]') if the test case has multiple steps.

    For test case “MM-T109 RN apps: User can’t send the same message repeatedly”, it should be:

    describe('Messaging', () => {
        it('MM-T109 User can\'t send the same message repeatedly', () => {
            // Test steps and assertion here

    Zephyr ID is used for mapping test cases per Release Testing specification. It will be used to measure coverage between manual and automated tests.

  3. Target an element using available matchers. For best results, it is recommended to match elements by unique identifiers using testID. The identifier should follow the following format to avoid duplication.



    • location - can be parent component, main section or UI screen.
    • modifier - adds meaning to the element.
    • element - common terms like button, text_input, image, and the like.
    • identifier - could be unique ID of a post, channel, team or user, or number to represent order.

    Notes: Not all fields are required. When assigning a testID, carefully inspect the actual render structure and pick up the minimum fields combination to create a unique value.


    • send.button
    • post.<post-id>
  4. Prefix each comment line with appropriate indicator. Each line in a multi-line comment should be prefixed accordingly. Separate and group test step comments and assertion comments for better readability.

    • # indicates a test step (e.g. // # Go to a screen)
    • * indicates an assertion (e.g. // * Check the title)
  5. Simulate user interaction using available actions.

  6. Verify user interface (UI) expectation using expect.

  7. When using action, match, or another API specific to particular platform, verify that the equivalent logic is applied so that the API does not impact the other platform. Always run tests in both platforms.

  8. See Detox documentation for reference.