Qase API

Qase provides Public API endpoints to perform actions with the entities stored in the database. The API is organized around the REST architecture.

Visit our API Documentation page, and check our Postman collection.

Basic Features

API Rate Limits: The API will accept upto 600 API requests per minute. Clients receive a HTTP 429 response, with a Retry-After: X header indicating a timeout period of 60 seconds, once the limit is exceeded.

Authentication: Qase.io uses API tokens to authenticate requests. You can manage tokens from the API Tokens page. All API requests must be made over HTTPS. Calls made over plain HTTP will fail. API requests without authentication will also fail.

Access control: Qase.io employs a Role-Based Access Control (RBAC) system to manage feature access within its web interface. These restrictions also apply to API methods. If your access rights are insufficient, the system will return a 403 status code error.

Token: Qase API expects the API key to be included in all API requests to the server in a header that looks like this: Token: <your-token>. Make sure to not share your API keys in publicly accessible areas like GitHub or client-side code.

How to use this resource?

This documentation is written to be read sequentially, much like a book.

Starting with the Introduction, which provides an overview of how Qase API and Reporters function. It explains the common features shared across all reporters, details the configuration options available, and describes how reporting works under various conditions.

The Introduction also covers how to use the Qase CLI tool to submit test results from JUnit or Allure report files.

If the framework or library you are using does not already have a supported reporter, we provide guidance to help you create a custom reporter, including links to relevant resources.

Use the arrow keys to navigate between pages. This resource is actively maintained, and we value your input! If you have suggestions to make it more useful, please don’t hesitate to reach out. 🙏

Why Qase?

As a complete TestOps platform, Qase centralizes test results from various sources and environments on a single platform to provide a unified space for your entire team to access and collaborate.

• Test run reports can be shared with any stakeholders, with a Public link.
• Test runs can be linked with external Issue trackers, to provide visibility.
• Derive insights from your runs, with Timeline charts and track overall progress with Dashboards.
• Query your data with Qase Query Language (QQL).

We’re commited to improving the tool, to accelerate testing – helping you acheive more, faster.

Qase CLI App (qli)

Qase CLI, or qli is the command line app for Qase, written in Go. qli can be used to start and complete test runs, and publish test results to Qase in several formats.

You can view the source code on GitHub

Installation Options

Install via go install

The easiest way to install Qase CLI is using go install:

go install github.com/qase-tms/qasectl@latest

Make sure to add $GOPATH/bin to your $PATH environment variable to be able to run the qasectl command. The binary is named qasectl, you may want to create an alias, as qli.

Build from Source

1. Clone the repository:

git clone https://github.com/qase-tms/qasectl.git && cd qasectl

2. Build the binary:

make build

You will find the binary in the build/ directory.

Try creating a test run by executing the binary:

./build/qli testops run create --project QD --token <your-token> --title "Run created from Qase-cli" --description "Hello, from qase-cli" --environment <env-slug> --verbose

Use a Docker Image

1. Pull the Docker image:

docker pull ghcr.io/qase-tms/qase-cli:latest

2. Run the Docker container:

docker run --rm ghcr.io/qase-tms/qase-cli:latest <add-your-command-here>

Using Qase CLI

You can generate an API token from here and refer to this guide to find your project code and run_id in Qase.

Create a Test Run

You can create a test run using the create command. This command creates a new test run in the specified project and saves a test run ID to a file.

You can specify the file path using the --output option. If not specified, the test run ID will be saved to qase.env in the current directory.

The file will contain the test run ID in the following format:

QASE_TESTOPS_RUN_ID=123

To extract the test run ID from file:

cat qase.env | grep QASE_TESTOPS_RUN_ID | cut -d'=' -f2

Example usage:

qli testops run create \
-p <project_code> \
-t <token> \
--title <title> \
-d <description> \
-e <environment> \
-m <milestone> \
-o <plan> \
-v

Create Command Options

Required:

• --project, -p: The project code where the test run will be created
• --token, -t: The API token to authenticate with the Qase API
• --title: The name of the test run

Optional:

• --description, -d: The description of the test run
• --environment, -e: The environment where the test run will be executed
• --milestone, -m: The milestone of the test run
• --plan: The test plan of the test run
• --output, -o: Output path to save the run Id (default: qase.env in working directory)
• --verbose, -v: Enable verbose mode

Example:

qli testops run create \
--project DEMO \
--token <token> \
--title "Example test run created using Qase CLI" \
--verbose

Complete a Test Run

Use the complete command to complete a test run in the specified project.

Example usage:

qli testops run complete \
--project <project_code> \
--token <token> \
--id <run_id> \
--verbose

The --id flag takes the ID of the Qase test run that is to be marked complete.

Example:

qli testops run complete --project DEMO --token <token> --id 1 --verbose

Upload Test Results

Use the upload command to upload test results for a test run in the specified project.

Example usage:

qli testops result upload \
--project <project_code> \
--token <token> \
--id <run_id> \
--format <format> \
--path <results_file> \
--batch <batch> \
--verbose

Upload Command Options

Required:

• --project, -p: The project code where the test results will be uploaded
• --token, -t: The API token to authenticate with the Qase API
• --id: The ID of the test run to upload results for (Required if title is not set)
• --title: The title of the test results (Required if id is not set)
• --path: The path to the test results file or folder
• --format: The format of the test results file (Allowed values: junit, qase, allure, xctest)

Optional:

• --description, -d: The description of the test results
• --steps: The mode of upload steps for XCTest (Allowed values: all, user)
• --batch: The batch number of the test results (Default: 200)
• --suite, -s: Define the root suite for all the test results
• --verbose, -v: Enable verbose mode

Example:

qli testops result upload \
--project DEMO \
--token <token> \
--id 1 \
--format junit \
--path /path/to/results.xml \
--verbose

Paths for different result types:

• Qase format: --path /path/to/build/qase-results/results.json
• Allure format: --path /path/to/allure-results
• XCTest format: --path /path/to/xctest-results

Create Environments and Milestones

Similar to creating test runs, use the create command to create a new environment or milestone in the specified project and save a value to a file.

The path for saving the qase.env file can be specified using the --output option. If not specified, qase.env will be saved to the working directory.

The file will contain:

QASE_ENVIRONMENT=<slug>

or

QASE_MILESTONE=<id>

To extract values from the file:

cat qase.env | grep QASE_ENVIRONMENT | cut -d'=' -f2

cat qase.env | grep QASE_MILESTONE | cut -d'=' -f2

Create Environment

Example usage:

qli testops env create --project <project_code> \
--token <token> \
--title <title> \
--slug <slug> \
--description <description> \
--host <host> \
--verbose

Required options:

• --project, -p: The project code where the test run will be created
• --token, -t: The API token to authenticate with the Qase API
• --title: The title of the Environment
• --slug: The slug value of the Environment

Optional options:

• --description, -d: The description of the test run
• --environment, -e: The environment where the test run will be executed
• --output, -o: Output path to save qase.env
• --verbose, -v: Enable verbose mode

Create Milestone

Example usage:

qli testops milestone create --project <project_code> \
--token <token> \
--title <title> \
--description <description> \
--status <status> \
--due-date <due_date> \
--verbose

Required options:

• --project, -p: The project code where the milestone will be created
• --token, -t: The API token to authenticate with the Qase API
• --title: The name of the milestone

Optional options:

• --description, -d: The description of the milestone
• --status, -s: The status of the milestone (Allowed values: active, completed)
• --due-date, -d: The due date of the milestone (Format: YYYY-MM-DD)
• --output, -o: Output path to save qase.env
• --verbose, -v: Enable verbose mode

Reporters

Configuration

The Reporter can be configured in multiple ways:

• using a config file qase.config.json
• using environment variables

All configuration options are listed in the table below:

Common

Qase Report configuration

Qase TestOps configuration

Example qase.config.json config:

{
  "mode": "testops",
  "fallback": "report",
  "debug": false,
  "environment": "local",
  "captureLogs": false,
  "report": {
    "driver": "local",
    "connection": {
      "local": {
        "path": "./build/qase-report",
        "format": "json"
      }
    }
  },
  "testops": {
    "api": {
      "token": "<token>",
      "host": "qase.io"
    },
    "run": {
      "title": "Regress run",
      "description": "Regress run description",
      "complete": true
    },
    "defect": false,
    "project": "<project_code>",
    "batch": {
      "size": 100
    }
  }
}

Javascript

JavaScript Commons

This module is an SDK for developing test reporters for Qase TMS. It’s using qaseio as an API client, and all Qase reporters are, in turn, using this package. You should use it if you’re developing your own test reporter for a special-purpose framework.

To report results from tests using a popular framework or test runner, don’t install this module directly and use the corresponding reporter module instead:

Changelog

Playwright

Playwright is an open-source automation framework for testing web applications across multiple browsers (Chromium, Firefox, WebKit).

It enables end-to-end testing, browser automation, and web scraping with a single API, supporting actions like navigating pages and interacting with UI elements.

Our playwright-qase-reporter allows you to upload the results of your automated test runs to your Qase project via the Qase’s public API.

Installation

To integrate Qase Reporter in your Playwright setup, follow these steps:

Activate the Playwright App

To activate the app, go to the Apps section in your workspace, and click on ‘Activate’.

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

add playwright-qase-reporter to your project

To install and add the reporter as a development dependency, run the following command in your node project ¹:

npm install -D playwright-qase-reporter

add the reporter to your playwright configuration file

At the very least, the reporter will need two variables defined — your playwright app’s token, and the Qase project you want to publish the results to:

 file: playwright.config.ts

import { defineConfig } from '@playwright/test';

export default defineConfig({
  reporter: [
    [
      'playwright-qase-reporter',
      {
       /* You can define the reporter options here, or in a separate file. */
        testops: {
          api: {
            token: '<app-token>',
          },
          project: '<project-code>',
        },
      },
    ],
  ],
};

Please refer to this article for guidance on how to find your Project code in Qase.

You can configure the reporter options in a separate file qase.config.json, placed in the root directory of your project.

{
  "testops": {
    "api": {
      "token": "<token>"
    },
    "project": "<project_code>"
  }
} 

Let’s verify the integration

We’ll use a simple test to check if the results are being published to your Qase project. Create a tests/ directory in the root of your project and add the following test:

const { test, expect } = require('@playwright/test');

test.describe('Example Test Suite', () => {
  test('A simple test to check the Playwright integration', () => {
    expect(true).toBe(true);
  });
});

Now, let’s run the test by executing the following command:

QASE_MODE=testops npx playwright test

In the above command, we’re setting the reporter’s mode to ‘testops’ using the environment variable QASE_MODE.

Syntax

Click here to view Example tests for the following syntax.

If you do not use any Qase syntax, the reporter uses the title from the describe and test functions to make the Suite and Test case titles while publishing results.

Example Spec file

import { qase } from 'playwright-qase-reporter';

describe('Suite title', () => {

  test(qase(1, "This is the test name"), () => {
    qase.title("This overrides the test name");
    qase.suite("Suite name");
    qase.fields({ 'severity': 'high', 'priority': 'medium' });
    qase.attach({ paths: './tests/examples/attachments/test-file.txt' });
    qase.comment("A comment for this result");
    qase.ignore(); // doesn't report his result to Qase.
    qase.parameters({ Username: "@test" }); 
    qase.groupParameters({ Username: username, Password: "123" });
    await test.step('Test step title', async () => // step logic });
   // test logic
  });

Import Statement

Add the following statement at the beginning of your spec file, before any tests.

import { qase } from 'playwright-qase-reporter';

Now, let’s take a closer look at each of the Qase functions.

Qase ID

Qase IDs can be defined using two different methods. It is best to select one method and consistently use it throughout your tests. The first method is recommended.

Only one Qase Id can be linked to a test.

Inline with the test Function:

test(qase(<id>, 'A simple test'), () => {
    ..

Inside the test Body:

test('A simple test', () => {
    qase.id(<id>);
     Test logic here
});

In the test’s annotations:

test('A simple test',
{
  annotation: { type: 'QaseID', description: '<id>' },
},
  async () => {
     Test logic here
});

Qase Title

The qase.title() method is used to set the title of a test case, both when creating a new test case from the result, and when updating the title of an existing test case - if used with qase.id().

test("This won't appear in Qase", () => {
  qase.title("This text will be the title of the test, in Qase");
  // Test logic here
});

If you don’t explicitly set a title using the qase.title method, the title specified in the test(..) function will be used for new test cases. However, if the qase.title method is defined, it always takes precedence and overrides the title from the test(..) function.

Steps

The reporter uses the title from the test.step function as the step title. By providing clear and descriptive step names, you make it easier to understand the test’s flow when reviewing the test case.

Additionally, these steps get their own result in the Qase Test run, offering a well-organized summary of the test flow. This helps quickly identify the cause of any failures.

test('A Test case with steps, updated from code', async () => {
  await test.step('Initialize the environment', async () => {
    // Set up test environment
  });
  await test.step('Test Core Functionality of the app', async () => {
    // Exercise core functionality
  });

  await test.step('Verify Expected Behavior of the app', async () => {
    // Assert expected behavior
  });

  await test.step('Verify if user is able to log out successfully', async () => {
    // Expected user to be logged out (but, ran into a problem!).
    expect(false).toBe(true);
  });
});

Fields

Currently, you can define description, pre & post conditions, and fields like severity, priority, layer with this method, allowing you to specify and maintain the context of the case, all directly from within your code.

test('Maintain your test meta-data from code', async () => {
  qase
    .title('Use qase annotation in a chain')
    .fields({
      severity: 'high',
      priority: 'medium',
      layer: 'api',
      description: `Code it quick, fix it slow,
                    Tech debt grows where shortcuts go,
                    Refactor later? Ha! We know.`
    })
    //  test logic here
});

Suite

You can use this method to nest the resulting test cases in a particular suite. There’s something to note here – suites, unlike test cases, are not identified uniquely by the Reporter. Therefore, when defining an existing suite - the title of the suite is used for matching.

test("Test with a defined suite", () => {
  qase.suite("Suite defined with qase.suite()");
    /*
     *  Or, nest multiple levels of suites. 
     *  `\t` is used for dividing each suite name.
     */
  qase.suite("Application\tAuthentication\tLogin\tEdge_case");
  //  test logic here
});

Parameters

Parameters are a great way to make your tests more dynamic, reusable, and data-driven. By defining parameters in this method, you can ensure only one test case with all the parameters is created in your Qase project, avoiding duplication.

const testCases = [
  { browser: "Chromium", username: "@alice", password: "123" },
  { browser: "Firefox", username: "@bob", password: "456" },
  { browser: "Webkit", username: "@charlie", password: "789" },
];

testCases.forEach(({ browser, username, password,  }) => {
  test(`Test login with ${browser}`, async () => {
    qase.title("Verify if page loads on all browsers");

    qase.parameters({ Browser: browser });  // Single parameter
  // test logic

testCases.forEach(({ username, password }) => {
  test(`Test login with ${username} using qase.groupParameters`, () => {
    qase.title("Verify if user is able to login with their username.");

    qase.groupParameters({  // Group parameters
      Username: username,
      Password: password,
    });
  // test logic

Comment

In addition to test.step(), this method can be used to provide any additional context to your test, it helps maintiain the code by clarifying the expected result of the test.

test("A test case with qase.comment()", () => {
    /*
     * Please note, this comment is added to a Result, not to the Test case.
     */
  qase.comment("This comment is added to the result");
  // test logic here
});

Attach

This method can help attach one, or more files to the test’s result. You can also add the file’s contents, directly from code. For example:

test('Test result with attachment', async () => {

       // To attach a single file
    qase.attach({
      paths: "./tests/examples/attachments/test-file.txt",
    });

       // Add multiple attachments. 
    qase.attach({ paths: ['/path/to/file', '/path/to/another/file'] });


       // Upload file's contents directly from code.
    qase.attach({ name: 'attachment.txt', content: 'Hello, world!', contentType: 'text/plain' });
      // test logic here
});

Ignore

If this method is added, the reporter will exclude the test’s result from the report sent to Qase. While the test will still executed by Playwright, its result will not be considered by the reporter.

test("This test is executed using Playwright; however, it is NOT reported to Qase", () => {
  qase.ignore();
//  test logic here

Update

Updating from v1.x.x

There are two changes:

1. Change the import paths:

   - import { qase } from 'playwright-qase-reporter/dist/playwright'
   + import { qase } from 'playwright-qase-reporter'
   

2. Update reporter configuration in playwright.config.js and/or environment variables — see the configuration reference below.

The previous test annotation syntax is still supported, so there is no need to rewrite the tests. However, check out the docs for the new, more flexible and powerful syntax.

changelog: playwright

For the most up-to-date changelog, please check our GitHub repository.

2.0.16

Improve excluding default steps, like Worker Cleanup, Before Hook, and After Hook.

2.0.15

Exclude Worker Cleanup step if it doesn’t have children steps.

2.0.14

Support specifying the test case ID in the annotation.

test('test',
  {
    annotation: { type: 'QaseID', description: '1' },
  },
  async ({ page }) => {
    await page.goto('https://example.com');
  });

2.0.13

Revert the qase.id() syntax to qase() for the Qase ID. The qase.id() syntax is still supported, but the qase() syntax is more concise and easier to use.

test(qase(42, 'test'), async ({ page }) => {
  await page.goto('https://example.com');
});

We decided to return the old syntax because in some situations the new syntax does not work, since the test does not run.

2.0.12

Exclude Before Hook and After Hook if they don’t have children steps.

2.0.11

Support group parameters for test cases. You can specify the group parameters in the test case using the following format:

  test('test', () => {
  qase.groupParameters({ 'param01': 'value01', 'param02': 'value02' });
  expect(true).toBe(true);
});

2.0.10

Improved stack trace handling when an error occurs. Now, records related to the reporter are not added to the stack trace.

2.0.9

Fixed the problem when tests have the same name and different QaseIDs. They were uploaded into the Qase with an incorrect QaseID.

2.0.7

Returned the ability to add the QaseID to the test name. This allows using the standard playwright mechanism to filter the tests being run.

2.0.6

Improve the collecting information about failed tests. Now, the reporter will collect the stack trace and the error message from all errors for failed tests.

2.0.5

The log message about the qase(id, 'title') annotation syntax got improved. Earlier it was saying that this syntax is deprecated, which could be understood as that it’s not working anymore, or will be removed any time. In fact, it’s still working and will be supported further on. However, there’s a more powerful and flexible syntax which we propose to try in new tests.

The updated log message will, hopefully, explain it better:

Some tests are using qase(id, ‘Title’) syntax. Consider using the new syntax: qase.id().title() in the test body. See the docs for reference: https://github.com/qase-tms/qase-javascript/tree/main/qase-playwright#readme

2.0.4

Added new annotation qase.comment(). Tests marked with it will be reported with the specified comment in the Qase.

test('test', async ({ page }) => {
  qase.comment("Custom comment");
  await page.goto('https://example.com');
});

2.0.3

Added new annotation qase.suite(). Tests marked with it will be reported to the specified suite in the Qase.

If you don’t specify the suite name, the reporter will take a suites from the test file path. If you use the root suite, the reporter will take the root suite as the first level of the suite and your value of the qase.suite() as the second level.

test('test', async ({ page }) => {
  qase.suite("Custom suite");
  await page.goto('https://example.com');
});

2.0.2

Added new annotation qase.ignore(). Tests marked with it will run as usual but won’t appear in the Qase report.

test('test', async ({ page }) => {
  qase.ignore();
  await page.goto('https://example.com');
});

2.0.1

Fixed an issue with using the qase.attach() method to add attachments with a file path. The reporter didn’t add such attachments to the test.

2.0.0

This is the first release in the 2.x series of the Playwright reporter. It brings a new annotation syntax with test parametrization and field values, new and more flexible configs, uploading results in parallel with running tests, and other powerful features.

This changelog entry will be updated soon. For more information about the new features and a guide for migration from v1, refer to the reporter documentation

2.0.0-beta.14

Fixed the issue with attachments that the Playwright would create if the test failed. We have not uploaded these attachments before. This problem has now been fixed.

2.0.0-beta.13

Fixed the issue with the qase.parameters annotation if you use not string values for parameters.

[ERROR] qase: Unable to add the result to the upstream reporter:
Message: Data is invalid.
 results.0.param.test_case: The param.test_case must be a string.

Error: Request failed with status code 400

Right now, the reporter will convert all parameters to strings before sending them to the Qase API.

2.0.0-beta.11

• Using the qase annotation in a chain

test('Ultimate Question of Life, The Universe, and Everything', async ({ page }) => {
  qase.id(42)
    .title('Ultimate Question of Life, The Universe, and Everything')
    .fields({ severity: high, priority: medium })
    .attach({ paths: '/path/to/file' });
...
})

2.0.0-beta.10

• Reporting no longer fails when a test has failed but no stacktrace was collected. (“TypeError: Cannot read properties of undefined (reading ‘toString’)”).

2.0.0-beta.9

Collect test suite information

Collect the following information as the test’s suite:

• path to the file which contains the test;
• value of the test.describe() declaration, if it exists.

The resulting test suite will be added to the test metadata. If Qase workspace is configured to update test cases from reported tests results, the newly created cases will be structured by their suites, derived from file path and test.describe().

2.0.0-beta.8

Fix the problem with dependencies, introduced in 2.0.0-beta.7

2.0.0-beta.7

Previously, we logged a message about the use of an outdated annotation immediately when running the test. Now we will log the message after all tests are completed. Like this:

qase: qase(caseId) is deprecated. Use qase.id() and qase.title() inside the test body
The following tests are using the old annotation:
at /Users/gda/Documents/github/qase-javascript/examples/playwright/test/arith.test.js:12:8
at /Users/gda/Documents/github/qase-javascript/examples/playwright/test/arith.test.js:16:7
at /Users/gda/Documents/github/qase-javascript/examples/playwright/test/arith.test.js:7:7

2.0.0-beta.6

Capture stdout and stderr logs as attachments. To enable this feature, set environment variable QASE_CAPTURE_LOGS=true or add captureLogs: true to the reporter configuration:

[
  'playwright-qase-reporter',
  {
    mode: 'testops', 
+   captureLogs: true,
    ...
  },
];

2.0.0-beta.5

Upload test attachments to Qase:

test('test', async ({ page }) => {
   upload files by path
  qase.attach({ paths: '/path/to/file' });
   list multiple files at once
  qase.attach({ paths: ['/path/to/file', '/path/to/another/file'] });
   upload contents directly from your code
  qase.attach({ name: 'attachment.txt', content: 'Hello, world!', contentType: 'text/plain' });
  await page.goto('https://example.com');
});

2.0.0-beta.4

Annotate parameterized tests to see the complete data in the Qase.io test report:

const people = ['Alice', 'Bob'];
for (const name of people) {
  test(`testing with ${name}`, async () => {
    qase.id(1)
    qase.parameters({ 'name': name });
     ...
  });
}

2.0.0-beta.3

• Change module exports for simpler importing.

  New syntax:

  import { qase } from 'playwright-qase-reporter';
  

  instead of:

  import { qase } from 'playwright-qase-reporter/playwright';
  

• Update the readme with examples of new imports and annotations.

2.0.0-beta.2

Overview

Qase reporter for the Playwright test framework.

This is a beta channel release. To try the new features, install it with:

npm install playwright-qase-reporter@beta

To switch back to the stable releases, run:

npm install playwright-qase-reporter@latest

New syntax for annotating tests

This release brings a major syntax change for specifying more test parameters.

Old syntax allowed only test ID and title, and wasn’t improving code readability:

test(qase(42, 'Ultimate Question of Life, The Universe, and Everything'), async ({ page }) => {
...
})

New syntax allows for adding information on separate lines, keeping the code readable:

test('Ultimate Question of Life, The Universe, and Everything', async ({ page }) => {
  qase.id(42);
  qase.fields({ severity: high, priority: medium });
  qase.attach({ paths: '/path/to/file' });
...
})

Cypress

Cypress is a purely JavaScript-based front-end testing tool built for the modern web. It aims to address the pain points developers or QA engineers face while testing an application. Cypress is a more developer-friendly tool that uses a unique DOM manipulation technique and operates directly in the browser.

With the cypress-qase-reporter, you can publish the results of your automated test runs to your Qase project using the public API.

Installation

To integrate Qase Reporter in your Cypress setup, follow these steps:

Activate the Cypress App

To activate the app, go to the Apps section in your workspace, and click on ‘Activate’.

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add cypress-qase-reporter to your project

To install and add the reporter as a development dependency, run the following in your node project:

npm install -D cypress-qase-reporter

Add the reporter to your Cypress configuration file

At the very least, the reporter will need two variables defined - your Cypress App’s Token, and the Qase Project you want to publish the results to.

const { defineConfig } = require('cypress');

module.exports = defineConfig({
    reporter: 'cypress-multi-reporters',
    reporterOptions: {
        reporterEnabled: 'cypress-qase-reporter',
        cypressQaseReporterReporterOptions: {
            mode: "testops",
            debug: true,
            testops: {
                api: {
                    token: '<app-token>',  // Replace with your Cypress app token
                },
                project: '<prj-code>',  // Replace with your Qase project code
                uploadAttachments: true,
                run: {
                    complete: true,
                },
            },
            framework: {
                cypress: {
                    screenshotsFolder: 'cypress/screenshots',
                }
            }
        },
    },
    video: false,
    e2e: {
        setupNodeEvents(on, config) {
            require('cypress-qase-reporter/plugin')(on, config);
            require('cypress-qase-reporter/metadata')(on);
        },
    },
});

The above example is using ES Module format. For a CommonJS version, please copy the code from here

If you already override before:run or after:run hooks in your cypress.config.js, configure your e2e section like this:

 ....

e2e: {
  setupNodeEvents(on, config) {
    require('cypress-qase-reporter/metadata')(on);
    on('before:run', async (details) => {
       your custom logic here
    });
    on('after:run', async () => {
       your custom logic here
    });
  },
}

Please refer to this article for guidance on how to find your Project code in Qase.

If you do not want to configure the reporter’s options in your Cypress configuration file, you have the option to use a qase.config.json to have all your reporter options defined.

Create a new qase.config.json file at the root of your repository, and add the project code and App token.

{
  "testops": {
    "api": {
      "token": "<token>"
    },
    "project": "<project_code>"
  }
}

Let’s verify the integration

We’ll use a simple test to check if the results are being published to your Qase project. Create a cypress/e2e/tests/ directory in the root of your project and add the following test:

 `example.cy.js`

describe('Simple Cypress Test', () => {

  it('Visits a webpage and checks the heading', () => {
     Step 1: Visit the webpage 
    cy.visit('https://example.com');  // Visit this page.
    cy.get('h1').should('have.text', 'Example Domain'); // Check title
  });
});

Now, let’s run the test by executing the following command:

QASE_MODE=testops npx cypress run

In the above command, we’re setting the reporter’s mode to testops using the Environment variable QASE_MODE.

Click on the link printed at the end of the run to go to the test run in Qase.

Syntax

Click here to view Example tests for the following syntax.

If you do not use any Qase syntax, the reporter uses the title from the describe and test functions to make the Suite and Test case titles while publishing results.

Example Spec file

describe("Demonstrates all Qase methods", () => {

  qase(1, it("This is the test name", () => {
    qase.title("This overrides the test name");
    qase.suite("Suite name");
    qase.fields({ priority: "high", severity: "critical" });
    qase.attach({ paths: "./path/to/attachment.txt" });
    qase.comment("This comment appears in the 'Actual Result' field.");
    qase.ignore(); // doesn't report his result to Qase.
    qase.parameters({ Browser: "Chromium" });
    qase.groupParameters({ Username: "@alice", Password: "123" });
    qase.step("Step 1: Open the site", () => // step logic );
   // test logic
  });
});

Import Statement

Add the following statement at the beginning of your spec file, before any tests.

import { qase } from "cypress-qase-reporter/mocha";

Now, let’s take a closer look at each of the Qase functions.

Qase Id

You can link multiple Qase Ids to a single test. Here’s an example:

qase(1, it("A single Qase Id", () => {
    // Test logic here
    ..
    
qase([2,3,4], it("Link multiple Qase Ids", () => {
    // Test logic here
    ..

Qase Title

The qase.title() method is used to set the title of a test case, both when creating a new test case from the result, and when updating the title of an existing test case - if used with qase.id().

it("This won't appear in Qase", () => {
  qase.title("This text will be the title of the test, in Qase");
  // Test logic here
});

If you don’t explicitly set a title using the qase.title method, the title specified in the test(..) function will be used for new test cases. However, if the qase.title method is defined, it always takes precedence and overrides the title from the test(..) function.

Steps

The reporter uses the title from the qase.step function as the step title. By providing clear and descriptive step names, you make it easier to understand the test’s flow when reviewing the test case.

Additionally, these steps get their own result in the Qase Test run, offering a well-organized summary of the test flow. This helps quickly identify the cause of any failures.

it("A Test case with steps, updated from code", () => {
   qase.step("Step 1: Open the site: qase.io", () => {
     // Step logic here
   });
 
   qase.step("Step 2: Click the 'Login' button", () => {
     // Step logic here
   });
 
   qase.step("Step 3: Check if the page loads successfully", () => {
     // Step logic here
   });
 });

Fields

Currently, you can define description, pre & post conditions, and fields like severity, priority, layer with this method, allowing you to specify and maintain the context of the case, all directly from within your code.

it("Demonstrates all Qase methods", () => {
   qase.fields({
     priority: "high",
     severity: "critical",
     layer: "e2e",
     description: "Example description",
     preconditions: "Example precondition",
     postconditions: "Example postcondition",
   });
   //  Test logic here
 });

Suite

You can use this method to nest the resulting test cases in a particular suite. There’s something to note here – suites, unlike test cases, are not identified uniquely by the Reporter.

Therefore, when defining an existing suite - the title of the suite is used for matching.

it("Test with a defined suite", () => {
   qase.suite("Suite defined with qase.suite()");
   /*
    *  Or, nest multiple levels of suites. 
    *  `\t` is used for dividing each suite name.
    */
   qase.suite("Suite defined with qase.suite()\tAuthentication\tLogin");
 
   expect(true).to.equal(true);
 });

Parameters

Parameters are a great way to make your tests more dynamic, reusable, and data-driven. By defining parameters in this method, you can ensure only one test case with all the parameters is created in your Qase project, avoiding duplication.

const testCases = [
  { browser: "Chromium", username: "@alice", password: "123" },
  { browser: "Firefox", username: "@bob", password: "456" },
  { browser: "Webkit", username: "@charlie", password: "789" },
];

testCases.forEach(({ browser }) => {
  it(`Test login with ${browser}`, () => {
    qase.title("Verify if page loads on all browsers");

      qase.parameters({ Browser: browser });  // Single parameter
  // test logic

testCases.forEach(({ username, password }) => {
  it(`Test login with ${username} using qase.groupParameters`, () => {
    qase.title("Verify if user is able to login with their username.");

      qase.groupParameters({  // Group parameters
        Username: username,
        Password: password,
        });
  // test logic

Comment

In addition to test.step(), this method can be used to provide any additional context to your test, it helps maintiain the code by clarifying the expected result of the test.

it("A test with qase.comment()", () => {
   /*
    * Please note, this comment is added to a Result, not to the Test case.
    */
   qase.comment("This comment is added to the result");
   // test logic here
 });

Attach

This method can help attach one, or more files to the test’s result. You can also add the file’s contents, directly from code. For example:

it("Test result with attachment", async () => {

   To attach a single file
  qase.attach({
    paths: "./cypress/e2e/tests/attachments/test-file.txt",
  });

     // Add multiple attachments. 
  qase.attach({ paths: ['/path/to/file', '/path/to/another/file'] });


     // Upload file's contents directly from code.
  qase.attach({ name: 'attachment.txt', content: 'Hello, world!', contentType: 'text/plain' });
    // test logic here
});

Ignore

If this method is added, the reporter will exclude the test’s result from the report sent to Qase. While the test will still executed by Cypress, its result will not be considered by the reporter.

it("This test is executed by Cypress, however, it is NOT reported to Qase", () => {
  qase.ignore();
  // test logic here
});

Update

Updating from v2.1 to v2.2

To update an existing test project using Qase reporter from version 2.1 to version 2.2, run the following steps:

1. Add a metadata in the e2e section of cypress.config.js

     ...
     e2e: {
      setupNodeEvents(on, config) { 
        require('cypress-qase-reporter/plugin')(on, config)
   +    require('cypress-qase-reporter/metadata')(on)
       }
     }
     ...
   

Updating from v1.x to v2.1

To update an existing test project using Qase reporter from version 1 to version 2.1, run the following steps:

1. Change import paths in your test files:

   - import { qase } from 'cypress-qase-reporter/dist/mocha'
   + import { qase } from 'cypress-qase-reporter/mocha'
   

2. Update reporter configuration in cypress.config.js and/or environment variables — see the configuration reference below.

3. Add a hook in the e2e section of cypress.config.js:

     ...
     e2e: {
   +   setupNodeEvents(on, config) { 
   +     require('cypress-qase-reporter/plugin')(on, config)
       }
     }
     ...
   

   If you already override before:run or after:run hooks in your cypress.config.js, use this instead:

   const { beforeRunHook, afterRunHook } = require('cypress-qase-reporter/hooks');
    
   ...
     e2e: {
       setupNodeEvents(on, config) {
   +     on('before:run', async () => {
   +       console.log('override before:run');
   +       await beforeRunHook(config);
   +     });
     
   +     on('after:run', async () => {
   +       console.log('override after:run');
   +       await afterRunHook(config);
   +     });
       },
     },
     ...
   

changelog: cypress

For the most up-to-date changelog, please check our GitHub repository.

2.2.5

Support Cucumber tests in Cypress with the cypress-cucumber-preprocessor plugin.

2.2.4

Fixed an issue with screenshots not being uploaded to Qase for failed tests.

2.2.3

Fixed an issue with the @cypress/grep plugin. When the grepOmitFiltered option is set to true, the reporter encounters an error.

Cannot set properties of undefined (setting 'title')

2.2.2

Fixed an issue with metadata. When specifying the path to the Cypress config located outside the root directory, metadata was not added to the test case.

2.2.1

When specifying test names, QaseIDs are now excluded from the final test name.

 The test name will be 'Example', not 'Example (Qase ID: 1)'
qase(1, it('Example', () => {
    expect(true).to.equal(true);
  })
);

2.2.0

Minor release of the Cypress reporter package

2.2.0-beta.3

Added the ability to add attachments to tests or steps:

• qase.attach - add an attachment to test or step

it('test', () => {
  qase.attach({ paths: '/path/to/file' });
  qase.step('Step 1', () => {
    cy.visit('https://example.com');
    qase.attach({ name: 'attachment.txt', content: 'Hello, world!', contentType: 'text/plain' });
  });
});

2.2.0-beta.2

Added the ability to add steps in tests:

• qase.step - add a step to the test

it('test', () => {
  qase.step('Step 1', () => {
    cy.visit('https://example.com');
  });
});

2.2.0-beta.1

Added the ability to specify a test metadata in tests:

• qase.title - set the test title
• qase.fields - set the test fields
• qase.suite - set the test suite
• qase.comment - set the test comment
• qase.parameters - set the test parameters
• qase.groupParameters - set the test group parameters
• qase.ignore - ignore the test in Qase

it('test', () => {
  qase.title('Title');
  qase.fields({ field: 'value' });
  qase.suite('Suite');
  qase.comment('Comment');
  qase.parameters({ param: 'value' });
  qase.groupParameters({ param: 'value' });
  qase.ignore();

  cy.visit('https://example.com');
});

2.1.0

Minor release of the Cypress reporter package

2.1.0-beta.3

Fixed an issue with the reporter completing the test run after each file with tests.

2.1.0-beta.1

• fixed an issue with the reporter completing the test run before all results are sent to Qase
• fixed an issue with the reporter not sending all results to Qase

Need to add the following to the cypress.config.js file:

...
  e2e: {
    setupNodeEvents(on, config) {
+      require('cypress-qase-reporter/plugin')(on, config);
    }
  }
...

2.0.3

Cypress doesn’t finish the process after the last test. The reporter will wait for all results to be sent to Qase and will not block the process after sending.

2.0.2

1. Cypress kills the process after the last tests. The reporter will wait for all results to be sent to Qase and will not block the process after sending.

2. The reporter will collect suites and add them to results.

2.0.1

The reporter would mark the test as blocked if the test was skipped in Cypress. Now, the reporter will mark the test as skipped.

2.0.0

This is the first release in the 2.x series of the Cypress reporter. It brings new and more flexible configs, uploading results in parallel with running tests, and other powerful features.

This changelog entry will be updated soon. For more information about the new features and a guide for migration from v1, refer to the reporter documentation

2.0.0-beta.3

Fixed an issue with multiple test runs created when Cypress is running multiple tests in parallel.

2.0.0-beta.2

First major beta release for the version 2 series of the Qase Cypress reporter.

CucumberJS

CucumberJS is a tool that runs automated tests written in plain language, making them easy for anyone on your team to understand. This accessibility promotes better communication, enhances collaboration, and builds trust within the team.

With the cucumberjs-qase-reporter you can publish the results of your automated test runs to your Qase project using the public API.

Installation

To integrate Qase Reporter in your CucumberJS setup, follow these steps:

Activate the CucumberJS App

To activate the app, go to the Apps section in your workspace, and click on ‘Activate’.

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add cucumberjs-qase-reporter to your project

To install and add the reporter as a development dependency, run the following in node project:

npm install -D cucumberjs-qase-reporter

Add a configuration file for the reporter

At the very least, the reporter will need two variables defined - your CucumberJS App’s Token, and the Qase Project you want to publish the results to:

// qase.config.json

{
  "debug": false,
  "testops": {
    "api": {
      "token": "<app-token>"
    },
    "project": "<project-code>",
    "run": {
      "complete": true
    }
  }
}

Please refer to this article for guidance on how to find your Project code in Qase.

Let’s verify the integration

We’ll use a simple test to check if the results are being published to your Qase project.

Create two directory in the root of your project - features/ and step_definitions/ Add the following to these directories:

// features/example.feature

Feature: Test Qase integration.

  Scenario: A scenario with multiple steps
    Given I have a step
    And I have another step
    When I do something
    Then I expect something to happen

// step_definitions/example_steps.js

Feature: Test Qase integration.

  Scenario: A scenario with multiple steps
    Given I have a step
    And I have another step
    When I do something
    Then I expect something to happen

Now, let’s run the test, by executing the following command:

QASE_MODE=testops npx cucumber-js -f cucumberjs-qase-reporter features -r step_definitions

In the above command, we’re setting the reporter’s mode to ‘testops’ using the Environment variable QASE_MODE.

Click on the link printed at the end of the run to go to the test run in Qase.

Syntax

changelog

For the most up-to-date changelog, please check our GitHub repository.

2.0.2

Support attachments in the test results.

const { Given, Then } = require('cucumber');

Given('I have a step with attachment', async function () {
  await this.attach('Hello, world!', 'text/plain');
});

Then('I have a step with attachment', async function () {
  await this.attach('Hello, world!', 'text/plain');
});

2.0.2

• Support QaseIgnore tag. If the test case has the QaseIgnore tag, the reporter will not send the result to the Qase TMS.

  @QaseIgnore
  Scenario: simple test
  

• Improved error handling.

2.0.0

This is the first release in the 2.x series of the Cucumber JS reporter. It brings a new annotation syntax with field values, new and more flexible configs, uploading results in parallel with running tests, and other powerful features.

This changelog entry will be updated soon. For more information about the new features and a guide for migration from v1, refer to the reporter documentation

2.0.0-beta.3

Added support new Qase tags.

-  @Q-1
+  @QaseID=2
+  @QaseTitle=Scenario_with_Qase_title_tag
+  @QaseFields={"description":"Description","severity":"high"}
  Scenario: simple test

QaseID - is a unique identifier of the test case in the Qase TMS. QaseTitle - is a title of the test case in the Qase TMS. QaseFields - is a JSON object with additional fields for the test case in the Qase TMS.

2.0.0-beta.2

Added support gherkin steps. Before this version, the reporter was not able to parse the steps from the feature files. Now, the reporter can parse the steps and send them to the Qase TMS.

2.0.0-beta.1

First major beta release for the version 2 series of the Qase Cypress reporter.

Mocha

Mocha is a powerful and flexible JavaScript testing framework that runs on Node.js and in the browser, making it suitable for testing both server-side and client-side applications. It supports various assertion libraries, allowing developers to write tests in a style that suits their preferences.

With the mocha-qase-reporter you can publish the results of your automated test runs to your Qase project using the public API.

Installation

To integrate Qase Reporter in your Mocha setup, follow these steps:

Activate the Mocha App

To activate the app, go to the Apps section in your workspace, and click on ‘Activate’

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add mocha-qase-reporter to your project

To install and add the reporter as a development dependency, run the following in node project:

npm install -D mocha-qase-reporter@beta

Add the reporter to your mocha configuration file

.mocharc.js:

module.exports = {
  reporter: "mocha-qase-reporter",
   ... other mocha options
}

At the very least, the reporter will need two variables defined - your Mocha App’s Token, and the Qase Project code you want to publish your results to.

We will create a new file qase.config.json at the root of your project to add these values.

qase.config.json:

{
  "debug": false,
  "testops": {
    "api": {
      "token": "<app-token>"
    },
    "project": "<project-code>",
    "run": {
      "complete": true
    }
  }
}

Please refer to this article for guidance on how to find your Project code in Qase.

Let’s verify the integration

We’ll use a simple test to check if the results are being published to your Qase project. Create a test/ directory in the root of your project and add the following test:

example.cy.js:

const assert = require('assert');

describe('Array', function() {
  describe('#indexOf()', function() {
    it('should return -1 when the value is not present', function() {
      assert.equal([1, 2, 3].indexOf(4), -1);
    });
  });
});

Now, let’s run the test

Execute the following command:

QASE_MODE=testops npx mocha

In the above command, we’re setting the reporter’s mode to ‘testops’ using the Environment variable QASE_MODE.

Click on the link printed at the end of the run to go to the test run in Qase.

Syntax

changelog: mocha

For the most up-to-date changelog, please check our GitHub repository.

1.0.0-beta.4

Fixed the issue with async tests not being reported correctly.

1.0.0-beta.3

Support group parameters for test cases. You can specify the group parameters in the test case using the following format:

  it('test', () => {
    this.groupParameters({ param1: 'value1', param2: 'value2' });
    expect(true).to.equal(true);
  });

1.0.0-beta.2

Support parallel execution of tests.

1.0.0-beta.1

First major beta release for the version 1 series of the Qase Mocha reporter.

WebDriverIO

WebdriverIO is an open-source testing framework for automating web applications using JavaScript or TypeScript. Built on the WebDriver protocol, it offers a simple API and supports various test frameworks like Mocha and Cucumber.

With the wdio-qase-reporter you can publish the results of your automated test runs to your Qase project using the public API.

Installation

To integrate Qase Reporter in your WebdriverIO setup, follow these steps:

Activate the WebdriverIO App

To activate the app, go to the Apps section in your workspace, and click on ‘Activate’

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Install wdio

Run npm init wdio@latest . to create a project in the current directory, and we’ll choose the following configuration for the purpose of this guide.

Configuration

Add wdio-qase-reporter to your project

To install and add the reporter as a development dependency, run the following in node project:

npm install -D wdio-qase-reporter@beta

Add the reporter to your configuration file

wdio.conf.ts:

import WDIOQaseReporter from 'wdio-qase-reporter';
import type { Options } from '@wdio/types';
import { afterRunHook, beforeRunHook } from 'wdio-qase-reporter';

export const config: Options.Testrunner = {
  reporters: [
    [
      WDIOQaseReporter, 
      {
        disableWebdriverStepsReporting: true,
        disableWebdriverScreenshotsReporting: true,
        useCucumber: false,
      }
    ]
  ],

   ...
   =====
   Hooks
   =====
  onPrepare: async function() {
    await beforeRunHook();
  },
  onComplete: async function() {
    await afterRunHook();
  },

   ... other options
};

Additional options to configure in the wdio.conf.ts file:

• disableWebdriverStepsReporting
  • Default: false
  • to not log custom steps to the reporter.
• disableWebdriverScreenshotsReporting
  • Default: false
  • do not attach screenshots to the reporter.
• useCucumber
  • Default: false
  • if you use Cucumber, enable this option.

At the very least, the reporter will need two variables defined - your WebdriverIO App’s Token, and the Qase Project code you want to publish your results to.

We will create a new file qase.config.json at the root of your project to add these values.

qase.config.json:

{
  "debug": false,
  "testops": {
    "api": {
      "token": "<app-token>"
    },
    "project": "<project-code>",
    "run": {
      "complete": true
    }
  }
} 

Please refer to this article for guidance on how to find your Project code in Qase.

Verify the integration

We’ll use the autogenerated login tests to check if the results are being published to your Qase project.

Let’s run the test, by executing the following command:

QASE_MODE=testops npx wdio run ./wdio.conf.ts

In the above command, we’re setting the reporter’s mode to ‘testops’ using the Environment variable QASE_MODE.

Click on the link printed at the end of the run to go to the test run in Qase.

Syntax

changelog: webdriverIO

For the most up-to-date changelog, please check our GitHub repository.

1.0.0-beta.4

Fix an issue with attaching the screenshot to the test case. Now, the reporter will correctly handle the screenshots and will attach them to the test case in the Qase TMS.

The first argument must be of type string or an instance of Buffer, ArrayBuffer, or Array or an Array-like Object. Received an instance of Object

1.0.0-beta.3

• Fix an issue with cucumber steps. Now, the reporter will correctly handle the cucumber steps and will report them to the Qase TMS.

• Fix an issue with duplicate test runs. Now, the reporter will correctly handle the test runs and will not create duplicate test runs in the Qase TMS.

  You need to add beforeRunHook hook to the onPrepare and afterRunHook hook to the onComplete in the wdio.conf.ts configuration file:

    import type { Options } from '@wdio/types'
    import WDIOQaseReporter from "wdio-qase-reporter";
    import { afterRunHook, beforeRunHook } from "wdio-qase-reporter";
  
    export const config: Options.Testrunner = {
     ...
    
     =====
     Hooks
     =====
     WebdriverIO provides several hooks you can use to interfere with the test process in order to enhance
     it and to build services around it. You can either apply a single function or an array of
     methods to it. If one of them returns with a promise, WebdriverIO will wait until that promise got
     resolved to continue.
    /**
     * Gets executed once before all workers get launched.
     * @param {object} config wdio configuration object
     * @param {Array.<Object>} capabilities list of capabilities details
     */
    onPrepare: async function() {
      await beforeRunHook();
    },
  
    /**
     * Gets executed after all workers got shut down and the process is about to exit. An error
     * thrown in the onComplete hook will result in the test run failing.
     * @param {object} exitCode 0 - success, 1 - fail
     * @param {object} config wdio configuration object
     * @param {Array.<Object>} capabilities list of capabilities details
     * @param {<Object>} results object containing test results
     */
    onComplete: async function() {
      await afterRunHook();
    },
  }
  

1.0.0-beta.2

Support group parameters for test cases. You can specify the group parameters in the test case using the following format:

  it('test', () => {
  qase.groupParameters({ 'param01': 'value01', 'param02': 'value02' });
  expect(true).to.equal(true);
});

1.0.0-beta.1

First major beta release for the version 1 series of the Qase WebDriverIO reporter.

Newman

Newman is a command-line Collection Runner for Postman. It enables you to run and test a Postman Collection directly from the command line. It’s built with extensibility in mind so that you can integrate it with your continuous integration (CI) servers and build systems.

With the newman-reporter-qase you can publish the results of your automated test runs to your Qase project using the public API.

Installation

To integrate Qase Reporter in your Newman setup, follow these steps:

Activate the Newman App

To activate the app, go to the Apps section in your workspace, and click on ‘Activate’

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add newman-reporter-qase to your project

To install and add the reporter as a development dependency, run the following in node project -

npm install -D newman-reporter-qase

Add a configuration file for the reporter

At the very least, the reporter will need two variables defined - your Newman App’s Token, and the Qase Project you want to publish the results to -

Please ensure that this file is placed in the root of your project.

// qase.config.json Add your token and project code to the JSON

{
  "debug": false,
  "testops": {
    "api": {
      "token": "<app-token>"
    },
    "project": "<project-code>"
  }
}

Please refer to this article for guidance on how to find your Project code in Qase.

Let’s verify the integration

We’ll use a simple test to check if the results are being published to your Qase project.

Create a collections/ directory in the root of your project and add the following test -

// example-collection.json

{
  "info": {
    "name": "Example API Tests",
    "_postman_id": "12345",
    "description": "A collection of API tests organized into a folder.",
    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
  },
  "item": [
    {
      "name": "User Tests",
      "item": [
        {
          "name": "Get Users",
          "request": {
            "method": "GET",
            "header": [],
            "url": {
              "raw": "https://jsonplaceholder.typicode.com/users",
              "protocol": "https",
              "host": [
                "jsonplaceholder",
                "typicode",
                "com"
              ],
              "path": [
                "users"
              ]
            }
          },
          "event": [
            {
              "listen": "test",
              "script": {
                "type": "text/javascript",
                "exec": [
                  "pm.test('Status code is 200', function () {",
                  "    pm.response.to.have.status(200);",
                  "});"
                ]
              }
            }
          ],
          "response": []
        }
      ]
    }
  ]
}

Now, let’s run the test, by executing the following command -

QASE_MODE=testops npx newman run -r qase collections/example-collection.json

In the above command, we’re setting the reporter’s mode to ‘testops’ using the Environment variable QASE_MODE.

Click on the link printed at the end of the run to go to the test run in Qase.

Syntax

changelog: newman

For the most up-to-date changelog, please check our GitHub repository.

2.0.3

Added support parameters from data files in Newman on collection and folder levels.

2.0.2

Added support parameters from data files in Newman. How to use parameters from data files in Newman, see here.

2.0.0

This is the first release in the 2.x series of the Newman reporter. It brings new and more flexible configs, uploading results in parallel with running tests, and other powerful features.

This changelog entry will be updated soon. For more information about the new features and a guide for migration from v1, refer to the reporter documentation

2.0.0-beta.2

Add support for suites in test results.

2.0.0-beta.1

First major beta release for the version 2 series of the Qase Newman reporter.

Jest

Jest is a powerful JavaScript testing framework developed by Meta, known for its ease of use and zero-config setup. It works well with any JavaScript project, especially React, and includes features like built-in assertions, snapshot testing, and mocking.

Jest runs tests in parallel for faster execution and automatically generates code coverage reports.

With the jest-qase-reporter you can publish the results of your automated test runs to your Qase project using the public API.

Installation

To integrate Qase Reporter in your Jest setup, follow these steps:

activate the jest app

To activate the app, go to the Apps section in your workspace, and click on ‘Activate’

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add jest-qase-reporter to your project

To install and add the reporter as a development dependency, run the following in node project -

npm install -D jest-qase-reporter

Add the reporter to your Jest configuration file

At the very least, the reporter will need two variables defined - your Jest App’s Token, and the Qase Project you want to publish the results to -

// jest.config.js

export default {
  reporters: [
    'default',
    [
      'jest-qase-reporter',
      {
        testops: {
          api: {
            token: 'api_key', // Replace with your actual API token
          },
          project: 'project_code', // Replace with your project code
          run: {
            complete: true,
          },
        },
        debug: true,
      },
    ],
  ],
   Other configurations...
};

*The above example is using *ES Module format, for a CommonJS version, copy the code from this toggle.

const defaultConfig = {
  reporters: [
    'default',
    [
      'jest-qase-reporter',
      {
        testops: {
          api: {
            token: 'api_key', // Replace with your actual API token
          },
          project: 'project_code', // Replace with your project code
          run: {
            complete: true,
          },
        },
        debug: true,
      },
    ],
  ],
  // Other configurations...
};

module.exports = defaultConfig;

Please refer to this article for guidance on how to find your Project code in Qase.

If you do not want to configure the reporter’s options in your Jest configuration file, you have the option to use a qase.config.json to have all your reporter options defined.

Create a new qase.config.json file at the root of your repository, and add the project code and App token.

{
  "testops": {
    "api": {
      "token": "<token>"
    },
    "project": "<project_code>"
  }
}

Let’s verify the integration

We’ll use a simple test to check if the results are being published to your Qase project.

Add the following sum function to the src/

// sum.js

function sum(a, b) {
  return a + b;
}

module.exports = sum;

Now, add the following test in the tests/ directory

const sum = require('../src/sum');

test('[Example] adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

Now, let’s run the test, by executing the following command -

QASE_MODE=testops npx jest sum

In the above command, we’re setting the reporter’s mode to ‘testops’ using the Environment variable QASE_MODE.

Click on the link printed at the end of the run to go to the test run in Qase.

Syntax

changelog: jest

For the most up-to-date changelog, please check our GitHub repository.

2.0.3

Added the ability to specify a test metadata in tests:

• qase.title - set the test title
• qase.fields - set the test fields
• qase.suite - set the test suite
• qase.comment - set the test comment
• qase.parameters - set the test parameters
• qase.groupParameters - set the test group parameters
• qase.ignore - ignore the test in Qase
• qase.attach - attach a file to the test
• qase.steps - add the test steps

const { qase } = require('jest-qase-reporter/jest');

test('test', () => {
  qase.title('Title');
  qase.fields({ custom_field: 'value' });
  qase.suite('Suite');
  qase.comment('Comment');
  qase.parameters({ param01: 'value' });
  qase.groupParameters({ param02: 'value' });
  qase.ignore();
  qase.attach({ name: 'attachment.txt', content: 'Hello, world!', type: 'text/plain' });

  qase.step('Step 1', () => {
    expect(true).toBe(true);
  });

  expect(true).toBe(true);
});

2.0.1

Fixed a bug when a test was marked as skipped. This reporter has uploaded this test as blocked. Right now the reporter will upload this test as skipped.

2.0.0

This is the first release in the 2.x series of the Jest reporter. It brings new and more flexible configs, uploading results in parallel with running tests, and other powerful features.

This changelog entry will be updated soon. For more information about the new features and a guide for migration from v1, refer to the reporter documentation

2.0.0-beta.2

• This release brings support for multiple changes made in the Qase API client and the qase-javascript-commons library.

2.0.0-beta.2

The v2 series of the Jest reporter has significant interface changes:

• New import path.
• New configuration data scheme.

See the README for reference and instructions on upgrading from v1.

TestCafe

We’ll be updating this guide, but in the meantime, please refer to instructions on our GitHub page.

- Qase Support

Installation

We’ll be updating this guide, but in the meantime, please refer to instructions on our GitHub page.

- Qase Support

Syntax

changelog: testcafe

For the most up-to-date changelog, please check our GitHub repository.

2.0.3

Support ignore metadata for test cases. If the test case has the ignore tag, the reporter will not send the result to the Qase TMS.

const q = qase.ignore().create();
test.meta({ ...q })(
  'test',
  async (t) => {
    await t;
  },
);

2.0.2

Improved error collection. The error stack trace contains more useful debugging information: browser, code, etc.

2.0.1

Support group parameters for test cases. You can specify the group parameters in the test case using the following format:

const q = qase.groupParameters({ 'param01': 'value01', 'param02': 'value02' }).create();
test.meta({ ...q })(
  'test',
  async (t) => {
    await t;
  },
);

2.0.0

This is the first release in the 2.x series of the TestCafe reporter. It brings a new annotation syntax with test parametrization and field values, new and more flexible configs, uploading results in parallel with running tests, and other powerful features.

This changelog entry will be updated soon. For more information about the new features and a guide for migration from v1, refer to the reporter documentation

2.0.0-beta.2

Add new syntax to annotate the following fields: QaseID, QaseTitle, QaseFields, QaseParameters:

+ import { qase } from 'testcafe-reporter-qase/qase';
 
- test.meta('CID', '2')('Test name', async t => {...});
+ const q = qase.id(2).title('Test name').fields('field1', 'field2').parameters('param1', 'param2').create();
+ test.meta(q)('Test name', async t => {...});

2.0.0-beta.1

First major beta release for the version 2 series of the Qase TestCafe reporter.

Python

Python Commons

This module is an SDK for developing test reporters for Qase TMS. It’s using qase-api-client as an API client, and all Qase reporters are, in turn, using this package. You should use it if you’re developing your own test reporter for a special-purpose framework.

To report results from tests using a popular framework or test runner, don’t install this module directly and use the corresponding reporter module instead:

Changelog

Pytest

Pytest is a Python testing framework that originated from the PyPy project. It can be used to write various types of software tests, including unit tests, integration tests, end-to-end tests, and functional tests. Its features include parametrized testing, fixtures, and assert re-writing.

With qase-pytest you can publish the results of your automated test runs to your Qase project using the public API.

Installation

To integrate Qase into your Pytest project, follow these steps:

Activate the Pytest App

To activate the app, go to the ‘Apps’ section in your workspace, and click on ‘Activate’

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add qase-pytest to your project

To install the reporter, run the following command in a virtual environment:

pip install qase-pytest

Add a configuration file for the reporter

At the very least, the reporter will need two variables defined - your Pytest App’s Token, and the Qase Project you want to publish the results to.

Please ensure that this file is placed in the root of your project.

qase.config.json:

{
  "testops": {
    "api": {
      "token": "<token>"
    },
    "project": "<project_code>"
  }
}

Please refer to this article for guidance on how to find your Project code in Qase.

Verify the integration

We’ll use a simple test to check if the results are being published to your Qase project. Create a tests/ directory in the root of your project and add the following test:

test_example.py:

def test_addition():
    assert 1 + 1 == 2

Now, let’s run the test by executing the following command:

QASE_MODE=testops pytest tests/test_example.py

In the above command, we’re setting the reporter’s mode to ‘testops’ using the Environment variable QASE_MODE. You can learn more about other reporter modes here.

Syntax

Update

From 5.x to 6.x

Import from qase

Import path has changed:

- from qaseio.pytest import qase
+ from qase.pytest import qase

Bulk uploading results has changed

In v5, two configuration options defined how the reporter was uploading results to Qase: testops.bulk and testops.chunk.

In v6, reporter always sends results in portions, called batches. Default batch size is 200, and can be set to anything from 1 to 2000. Update the config in the following way:

{
  "testops": {
-   "bulk": true, 
-   "chunk": 100
+   "batch": {
+     "size": 100
+   }
  }
}

From 4.x to 5.x

Configuration

In the latest version of the qase-pytest reporter, we have updated the way configuration is handled. The primary source of truth is now a configuration file named qase.config.json.

This file must be located at the root of the directory from which you run your tests. This change not only makes the configuration process more flexible but also allows us to introduce more configuration options in the future. This new config structure will be applicable to all other reporters as well.

Also, we have changed the names of ENV variables and CLI options. You can find the list of all available options in the configuration section.

New context decorators

We have added new context decorators for fields to make them more flexible and reduce the amount of manual work.

Instead of using @qase.priority(), @qase.severity(), @qase.layer() decorators,

you can use @qase.field("priority", "high"), @qase.field("severity", "critical"), @qase.field("layer", "unit") decorators.

For Custom fields, you can use @qase.field("custom_field", "value") to add custom fields to your test case.

Old decorators will be removed in the next major release.

Selective execution

Starting with 5.0 version, we have added a new feature that allows you to run only tests that are linked to test cases in Qase TestOps. That changes the behavior of test_plan_id parameter. Now, if you specify one of these parameters, the reporter will run only tests that are linked to test cases in the specified test plan.

changelog: pytest

For the most up-to-date changelog, please check our GitHub repository.

6.1.9

Fixed an issue with parameters:

INTERNALERROR>   File "/venv/lib/python3.9/site-packages/qase/pytest/plugin.py", line 331, in _set_params
INTERNALERROR>     value = str(ids[i])
INTERNALERROR> IndexError: list index out of range

6.1.8

Fixed an issue with suites [#296]

6.1.7

Support new version of qase-python-commons

6.1.6

Fixed an issue with the handling video and trace recording for Playwright tests. If a test was part of a class, the video and trace were not attached to the test result.

6.1.5

Improved the handling of videos and traces for Playwright tests. You don’t need to create a conftest.py file anymore. The video and trace will be attached to the test result automatically. You can configure the video and trace recording using the following parameters:

• --video on - add a video to each test
• --video retain-on-failure - add a video to each filed test
• --tracing on - add a trace to each test
• --tracing retain-on-failure - add a trace to each filed test
• --output - the directory where the video and trace will be saved. By default, the video and trace will be saved in the test-results directory.

6.1.4

Improve handling parameters in the pytest.mark.parametrize decorator. If you specify the ids parameter, the reporter will use it as value of parameter in the test case.

@pytest.mark.parametrize("enter", [enter_from_meta, enter_from_expedition, enter_from_news],
                         ids=["enter_from_meta", "enter_from_expedition", "enter_from_news"])
def test_enter(enter):
    enter()

6.1.3

If a video is attached to the result, it will be added as an attachment. You can configure this functionality using the “video” parameter:

• --video on - add a video to each test
• --video retain-on-failure - add a video to each filed test

6.1.2

Fixed an issue with the pytest-xdist that caused the tests to be run in parallel and completed the test run before the results were uploaded to Qase.

6.1.1

Minor release that includes all changes from beta versions 6.1.1b.

6.1.1b5

Fixed an issue with network profiler.

6.1.1b4

Fixed an issue with parameters like this:

@pytest.mark.parametrize(argnames="foo", argvalues=["bar", "baz"])

The error was:

INTERNALERROR> File "/usr/local/lib/python3.12/site-packages/qase/pytest/plugin.py", line 79, in pytest_collection_modifyitems
INTERNALERROR> param_name, values = mark.args
INTERNALERROR> ^^^^^^^^^^^^^^^^^^
INTERNALERROR> ValueError: not enough values to unpack (expected 2, got 0)

6.1.1b3

Fix an issue with the video recording option when the test fails:

INTERNALERROR>     video = item.funcargs['page'].video
INTERNALERROR>             ~~~~~~~~~~~~~^^^^^^^^
INTERNALERROR> KeyError: 'page'

6.1.1b2

If the video recording option is enabled and the test fails, the video will be attached to the test result when using Playwright.

For configuration, you should create a conftest.py file in the root of your project and add the following code:

import pytest


# Configure Playwright to record video for all tests
@pytest.fixture(scope="session")
def browser_context_args(browser_context_args):
    return {
        **browser_context_args,
        "record_video_dir": "./videos",  # Directory where videos will be saved
        "record_video_size": {"width": 1280, "height": 720}  # Video resolution
    }

6.1.1b1

Support pytest-rerunfailures plugin. This plugin allows you to rerun failed tests. Each test run will be uploaded as a separate result in Qase.

6.1.0

Minor release that includes all changes from beta versions 6.1.0b. And also added support for group parameters.

6.1.0b4

• Exclude the default parameters that are added by additional libraries and start with __pytest
• If you use the testops mode and specify a plan ID then the reporter will run the tests specified in the test plan based on their IDs.

6.1.0b3

Fixed an issue then qase-pytest-capture-logs parameter did not set correct value.

6.1.0b2

Fixed the following issues:

• issue with qase-pytest-capture-logs parameter [#234]. When using the “qase-pytest-capture-logs” parameter, an error occurred: pytest: error: unrecognized arguments: --qase-pytest-capture-logs=true

• issue with qase-testops-batch-size parameter [#235]. When using the “qase-testops-batch-size” parameter, an error occurred: TypeError: '>' not supported between instances of 'str' and 'int'

6.1.0b1

Implemented a method that constructs a signature for each test result. It takes the file path, suites, qase IDs, and parameters.

6.0.3

Fixed the issue where the suite specified in the decorator was not displayed. Fix [#231]

6.0.2

Fixed the issue [#226]:

TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'

6.0.1

Changed the name of the complete test run parameter for CLI arguments. Fix [#160]

6.0.0

The first release in the 6.0.x series of the Pytest reporter.

6.0.0b2

Turn off the sleep profiler until the test data collection is completed. Now the profilers will turn off after the test is completed.

Playwright Python

Robotframework

Robot Framework is a generic test automation framework for acceptance testing and acceptance test-driven development. It is a keyword-driven testing framework that uses tabular test data syntax.

With qase-robotframework you can publish the results of your automated test runs to your Qase project using the public API endpoints.

Installation

To integrate Qase into your project, follow these steps:

Activate the Robot Framework App

1. To activate the app, go to the ‘Apps’ section in your workspace, and click on ‘Activate’.
2. Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token, as we’ll need it in the following steps.

Add qase-robotframework to your project

To install the reporter, run the following command in a virtual environment 🔗:

pip install qase-robotframework

Add a configuration file for the reporter

At the very least, the reporter will need two variables defined – your Robot Framework App’s Token, and the Qase Project you want to publish the results to:

Ensure that this file is placed in the root of your project.

{
  "debug": false,
  "testops": {
    "api": {
      "token": "<app-token>"
    },
    "project": "<project-code>"
  }
}

Please refer to this article for guidance on how to find your Project code in Qase.

Let’s verify the integration, we’ll use a simple test to check if the results are being published to your Qase project. Create a tests/ directory in the root of your project and add the following test:

*** Test Cases ***
Simple Addition Test
    ${result}=    Evaluate    1 + 1
    Should Be Equal    ${result}    2

Now, let’s run the test by executing the following command:

QASE_MODE=testops robot --listener qase.robotframework.Listener ./tests/test_addition.robot`

In the above command, we’re setting the reporter’s mode to ‘testops’ using the Environment variable QASE_MODE. You can learn more about other reporter modes here.

Click on the link printed by qase-robotframework to go to the test run in Qase.

Syntax

changelog: robotframework

For the most up-to-date changelog, please check our GitHub repository.

3.2.1

Support new version of qase-python-commons

3.2.0

Minor release that includes all changes from beta versions 3.2.0b.

Support pabot library. If you use the pabot library to run tests in parallel, the reporter will send the results

3.2.0b3

Improve handling of nested steps in the Robot Framework listener.

For example, if the test has the following structure:

Formatted Return
    RETURN  ${value}

Previously, the RETURN keyword was presented as RETURN in the Qase test run. Now, the keyword is presented as RETURN ${value}.

3.2.0b2

Fix an issue with nested steps in the Robot Framework listener.

3.2.0b1

• Migrate the listener to the ROBOT_LISTENER_API_VERSION version 3.
• Support a selective execution of tests by Qase ID. If the plan id is specified, the reporter will send the results only for the tests that are in the plan.

3.1.2

Support qase.fields tag. You can specify the fields that you want to send to Qase.

Simple test
    [Tags]     qase.fields:{ "suite": "my suite", "description": "It is simple test" }
    Should Be Equal As Numbers    1    1

3.1.1

Minor release that includes all changes from beta versions 3.1.1b.

Support qase.ignore tag. If the test has the qase.ignore tag, the reporter will not send the result to Qase.

Simple test
    [Tags]     qase.ignore
    Should Be Equal As Numbers    1    1

3.1.1b2

Fixed the issue:

Calling method 'end_test' of listener 'qase.robotframework.Listener' failed: IndexError: list index out of range

3.1.1b1

Add support robotframework-tidy to the reporter. The reporter will ignore IF, ELSE IF, ELSE, and END keywords.

3.1.0

Minor release that includes all changes from beta versions 3.1.0b.

3.1.0b3

Added the ability to attach attachments to step implementations.

from qase.robotframework.method import qase


def step01(a: int, b: int):
    qase.attach("/some_path/file.xml")
    qase.attach((str.encode("This is a simple string attachment"), "text/plain", "simple.txt"))
    return str(a + b)

3.1.0b1

Implemented a method that constructs a signature for each test result. It takes the file path, suites, qase IDs, and parameters.

3.0.0

The first release in the 3.0.x series of the Robot Framework reporter.

3.0.0b4

The reporter will now extract the Qase ID after ending the test, not before.

3.0.0b3

Fixed the issue:

AttributeError: 'Result' object has no attribute 'case'

Renamed the internal package from qaseio to qase.

3.0.0b2

Fixed an issue with unsupported step status. If the step is skipped, mark such a step as blocked in the Qase test run.

Syntax

Syntax

Configuration

Java

Java Commons

This module is an SDK for developing test reporters for Qase TMS. It’s using qase-api-client as an API client, and all Qase reporters are, in turn, using this package. You should use it if you’re developing your own test reporter for a special-purpose framework.

To report results from tests using a popular framework or test runner, don’t install this module directly and use the corresponding reporter module instead:

Changelog

Cucumber

Cucumber 7

Cucumber is a testing library that allows you to write your tests in plain language. It follows the given-when-then structure, but as you’ll see the tests are very readable. Even by business users. This allows your tests to be a point of communication and collaboration.

With our Cucumber reporters you can publish the results of your automated test runs to your Qase project using the public API endpoints.

Installation

To integrate Qase into your project, follow these steps -

Activate the Cucumber7 App

To activate the app, go to the Apps section in your workspace, and click on ‘Activate’

Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add the reporter to your project

For Maven Projects

Run the following command to quickly initialize a new project -

mvn archetype:generate \
  "-DarchetypeGroupId=io.cucumber" \
  "-DarchetypeArtifactId=cucumber-archetype" \
  "-DarchetypeVersion=7.18.1" \
  "-DgroupId=hellocucumber" \
  "-DartifactId=qase-cucumber7" \
  "-Dpackage=hellocucumber" \
  "-Dversion=1.0.0-SNAPSHOT" \
  "-DinteractiveMode=false"

Here’s an example pom.xml that has all the required dependencies - Link.

To install and add the reporter as a dependency, add the following to your pom.xml -

<properties>
   <aspectj.version>1.9.22</aspectj.version>
   <cucumber.version>7.14.0</cucumber.version>
   <maven.compiler.source>1.8</maven.compiler.source>
   <maven.compiler.target>1.8</maven.compiler.target>
</properties>

<dependencies>
   <dependency>
      <groupId>io.qase</groupId>
      <artifactId>qase-cucumber-v7-reporter</artifactId>
      <version>4.0.0</version>
      <scope>test</scope>
   </dependency>
   <dependency>
      <groupId>io.cucumber</groupId>
      <artifactId>cucumber-core</artifactId>
      <version>${cucumber.version}</version>
      <scope>test</scope>
   </dependency>
   <dependency>
      <groupId>io.cucumber</groupId>
      <artifactId>cucumber-java</artifactId>
      <version>${cucumber.version}</version>
      <scope>test</scope>
   </dependency>
   <dependency>
      <groupId>io.cucumber</groupId>
      <artifactId>cucumber-testng</artifactId>
      <version>${cucumber.version}</version>
      <scope>test</scope>
   </dependency>
   <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>7.1.0</version>
      <scope>test</scope>
   </dependency>
   <dependency>
      <groupId>org.aspectj</groupId>
      <artifactId>aspectjweaver</artifactId>
      <version>${aspectj.version}</version>
      <scope>test</scope>
   </dependency>
</dependencies>

<build>
   <plugins>
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-surefire-plugin</artifactId>
         <version>3.0.0-M5</version>
         <configuration>
            <argLine>
               -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
            </argLine>
         </configuration>
         <dependencies>
            <dependency>
               <groupId>org.aspectj</groupId>
               <artifactId>aspectjweaver</artifactId>
               <version>${aspectj.version}</version>
            </dependency>
         </dependencies>
      </plugin>
   </plugins>
</build>

For Gradle Projects

configurations {
   aspectjweaver
}

tasks.withType(JavaCompile).configureEach {
   // Enables the adapter to accept real parameter names
   options.compilerArgs.add("-parameters")
}

def cucumberVersion = "7.14.0"

dependencies {
   aspectjweaver "org.aspectj:aspectjweaver:1.9.22"
   testImplementation platform('org.junit:junit-bom:5.10.0')
   testImplementation "io.cucumber:cucumber-core:$cucumberVersion"
   testImplementation "io.cucumber:cucumber-java:$cucumberVersion"
   testImplementation "io.cucumber:cucumber-testng:$cucumberVersion"
   testImplementation 'org.testng:testng:7.1.0'
   testImplementation("io.qase:qase-cucumber-v7-reporter:4.0.0")
}

test {
   systemProperties = System.properties
}

test.doFirst {
   useTestNG()
   def weaver = configurations.aspectjweaver.find { it.name.contains("aspectjweaver") }
   jvmArgs += "-javaagent:$weaver"
}

Let’s verify the integration

We’ll use a simple test that is included in the example project to check if the results are being published to your Qase project.

Replace this file in src/test/java/hellocucumber/ directory, with the code below -

 RunCucumberTest.java   

package hellocucumber;

import org.junit.platform.suite.api.ConfigurationParameter;
import org.junit.platform.suite.api.IncludeEngines;
import org.junit.platform.suite.api.SelectPackages;
import org.junit.platform.suite.api.Suite;

@Suite
@IncludeEngines("cucumber")
@SelectPackages("hellocucumber")

public class RunCucumberTest {
}

Now, let’s run the test, by executing the following command -

mvn clean test -DQASE_MODE=testops -DQASE_TESTOPS_PROJECT=<prj-code> -DQASE_TESTOPS_API_TOKEN=<app-token>

For Gradle

gradle clean test -DQASE_MODE=testops -DQASE_TESTOPS_PROJECT=<prj-code> -DQASE_TESTOPS_API_TOKEN=<app-token>

Please refer to this article for guidance on how to find your Project code in Qase. In the above command, we’re setting the reporter’s mode with QASE_MODE.

You should see the following summary at the end of the execution -

Here’s how your Qase Test run should look like -

Syntax

changelog: cucumber 7

For the most up-to-date changelog, please check our GitHub repository.

Cucumber 6

Cucumber 6

Syntax

changelog: cucumber 6

For the most up-to-date changelog, please check our GitHub repository.

Cucumber 5

Cucumber 5

Syntax

changelog: cucumber 5

For the most up-to-date changelog, please check our GitHub repository.

Cucumber 4

Cucumber 4

Syntax

changelog: cucumber 4

For the most up-to-date changelog, please check our GitHub repository.

Junit

Junit 5

JUnit is an open source framework, which is used for writing and running tests. Provides annotations to identify test methods. Provides assertions for testing expected results. Provides test runners for running tests.

With the JUnit5 reporter you can publish the results of your automated test runs to your Qase project using the public API endpoints.

Installation

To integrate Qase into your project, follow these steps -

Activate the JUnit5 App

1. To activate the app, go to the Apps section in your workspace, and click on ‘Activate’
2. Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add the reporter to your project

For Maven Projects

To quickly initialise a new project, run the following command -

To install and add the reporter as a dependency, add the following to your pom.xml:

<properties>
  <aspectj.version>1.9.22</aspectj.version>
  <maven.compiler.source>1.8</maven.compiler.source>
  <maven.compiler.target>1.8</maven.compiler.target>
</properties>

<dependencies>
  <dependency>
     <groupId>io.qase</groupId>
     <artifactId>qase-junit5-reporter</artifactId>
     <version>4.0.0</version>
     <scope>test</scope>
  </dependency>
  <dependency>
     <groupId>org.junit</groupId>
     <artifactId>junit-bom</artifactId>
     <version>5.11.2</version>
     <type>pom</type>
     <scope>test</scope>
  </dependency>
  <dependency>
     <groupId>org.junit.jupiter</groupId>
     <artifactId>junit-jupiter-api</artifactId>
     <version>5.11.2</version>
     <scope>test</scope>
  </dependency>
  <dependency>
     <groupId>org.junit.jupiter</groupId>
     <artifactId>junit-jupiter-params</artifactId>
     <version>5.11.2</version>
     <scope>test</scope>
  </dependency>
</dependencies>

<build>
  <plugins>
     <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.0.0-M5</version>
        <configuration>
           <argLine>
              -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
           </argLine>
           <!-- This section is required for the proper functioning of the reporter. -->
           <properties>
              <configurationParameters>
                 junit.jupiter.extensions.autodetection.enabled = true
              </configurationParameters>
           </properties>
        </configuration>
        <dependencies>
           <dependency>
              <groupId>org.aspectj</groupId>
              <artifactId>aspectjweaver</artifactId>
              <version>${aspectj.version}</version>
           </dependency>
        </dependencies>
     </plugin>
  </plugins>
</build>

For Gradle Projects

Include the following to your build.gradle:

configurations {
   aspectjweaver
}

tasks.withType(JavaCompile).configureEach {
   // Enables the adapter to accept real parameter names
   options.compilerArgs.add("-parameters")
}

dependencies {
   aspectjweaver "org.aspectj:aspectjweaver:1.9.22"
   testImplementation platform('org.junit:junit-bom:5.10.0')
   testImplementation 'org.junit.jupiter:junit-jupiter'
   testImplementation 'org.junit.jupiter:junit-jupiter-api'
   testImplementation 'org.junit.jupiter:junit-jupiter-params'
   testImplementation 'org.junit.jupiter:junit-jupiter-engine'
   testImplementation 'org.junit.platform:junit-platform-launcher'
   testImplementation('io.qase:qase-junit5-reporter:4.0.0')
}

test {
   systemProperties = System.properties
}

compileTestJava {
   options.getCompilerArgs().add("-parameters")
}

test.doFirst {
   useJUnitPlatform()
   // This line is required for the proper functioning of the reporter.
   systemProperty "junit.jupiter.extensions.autodetection.enabled", true
   def weaver = configurations.aspectjweaver.find { it.name.contains("aspectjweaver") }
   jvmArgs += "-javaagent:$weaver"
}

Let’s verify the integration

We’ll use a simple test to check if the results are being published to your Qase project.

Replace the file in src/test/java/com/example/ directory (your path may differ) with the code below:

 AppTest.java   

package com.example;

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.assertTrue;
import io.qase.commons.annotation.*;

public class AppTest 
{
    @Test
    @QaseTitle("Test Integration")
    public void testApp()
    {
        assertTrue(true); // A simple test that always passes
    }
}

Now, let’s run the test, by executing the following command:

Maven

mvn clean test -DQASE_MODE=testops -DQASE_TESTOPS_PROJECT=<prj-code> -DQASE_TESTOPS_API_TOKEN=<app-token>

Gradle

gradle clean test -DQASE_MODE=testops -DQASE_TESTOPS_PROJECT=<prj-code> -DQASE_TESTOPS_API_TOKEN=<app-token>

Please refer to this article for guidance on how to find your Project code in Qase. In the above command, we’re setting the reporter’s mode with QASE_MODE.

You should see the following summary at the end of the execution:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running com.example.AppTest
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.262 s - in com.example.AppTest
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  3.449 s
[INFO] Finished at: 2023-11-07T12:00:00Z
[INFO] ------------------------------------------------------------------------

Here’s how your Qase Test run should look like:

Syntax

changelog: junit 5

For the most up-to-date changelog, please check our GitHub repository.

Junit 4

Junit 4

Syntax

changelog: junit 4

For the most up-to-date changelog, please check our GitHub repository.

TestNG

TestNG is a testing framework for the Java programming language created by Cédric Beust and inspired by JUnit and NUnit. The design goal of TestNG is to cover a wider range of test categories: unit, functional, end-to-end, integration, etc., with more powerful and easy-to-use functionalities.

With our TestNG reporter, you can publish the results of your automated test runs to your Qase project using the public API endpoints.

Installation

To integrate Qase into your project, follow these steps:

Activate the TestNG App

1. To activate the app, go to the Apps section in your workspace, and click on ‘Activate’.
2. Switch to the ‘Access tokens’ tab, and create a new API token from here. Save the API token as we’ll need it for the next steps.

Add the reporter to your project

For Maven Projects

To quickly initialize a new project, run the following command:

mvn archetype:generate -DgroupId=com.example -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DarchetypeVersion=1.4 -DinteractiveMode=false

To install and add the reporter as a dependency, add the following to your pom.xml:

<properties>
   <aspectj.version>1.9.22</aspectj.version>
</properties>

<dependencies>
   <dependency>
      <groupId>io.qase</groupId>
      <artifactId>qase-testng-reporter</artifactId>
      <version>4.0.0</version>
      <scope>test</scope>
   </dependency>
   <dependency>
      <groupId>org.testng</groupId>
      <artifactId>testng</artifactId>
      <version>7.1.0</version>
      <scope>test</scope>
   </dependency>
</dependencies>

<build>
   <plugins>
      <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-surefire-plugin</artifactId>
         <version>3.0.0-M5</version>
         <configuration>
            <argLine>
               -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
            </argLine>
         </configuration>
         <dependencies>
            <dependency>
               <groupId>org.aspectj</groupId>
               <artifactId>aspectjweaver</artifactId>
               <version>${aspectj.version}</version>
            </dependency>
         </dependencies>
      </plugin>
   </plugins>
</build>

You can also use this example pom.xml: Link

For Gradle Projects

Include the following in your build.gradle:

configurations {
   aspectjweaver
}

tasks.withType(JavaCompile).configureEach {
   // Enables the adapter to accept real parameter names
   options.compilerArgs.add("-parameters")
}

dependencies {
   aspectjweaver "org.aspectj:aspectjweaver:1.9.22"
   testImplementation 'io.qase:qase-testng-reporter:4.0.0'
   testImplementation 'org.testng:testng:7.1.0'
}

test {
   systemProperties = System.properties
}

test.doFirst {
   useTestNG()
   def weaver = configurations.aspectjweaver.find { it.name.contains("aspectjweaver") }
   jvmArgs += "-javaagent:$weaver"
}

Let’s verify the integration

We’ll use a simple test to check if the results are being published to your Qase project.

Replace the file in src/test/java/com/example/ directory (your path may differ) with the code below:

 AppTest.java   
package com.example;

import org.testng.annotations.Test;
import static org.testng.Assert.assertTrue;
import io.qase.commons.annotation.*;

public class AppTest {

    @Test
    @QaseTitle("Test Integration")
    public void testApp() {
        assertTrue(true); // A simple test that always passes
    }
}

Now, let’s run the test by executing the following command:

Maven

mvn clean test -DQASE_MODE=testops -DQASE_TESTOPS_PROJECT=<prj-code> -DQASE_TESTOPS_API_TOKEN=<app-token>

Gradle

gradle clean test -DQASE_MODE=testops -DQASE_TESTOPS_PROJECT=<prj-code> -DQASE_TESTOPS_API_TOKEN=<app-token>

Please refer to this article for guidance on how to find your Project code in Qase.

Please refer to this article for guidance on how to find your Project code in Qase. In the above command, we’re setting the reporter’s mode with QASE_MODE.

You should see the following summary at the end of the execution:

21:11:04.568 [main] INFO i.q.commons.reporters.CoreReporter - Completing test run
21:11:04.888 [main] INFO io.qase.commons.client.ApiClientV1 - Test run link: https://app.qase.io/run/QD/dashboard/1859
21:11:04.888 [main] INFO i.q.c.reporters.TestopsReporter - Test run 1859 completed
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.985 s - in com.example.AppTest
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[INFO]
===================================
           BUILD SUCCESS
===================================
[INFO]
[INFO] Total time: 4.662 s
Finished at: 2024-11-07T21:11:05+05:30
===================================

Here’s how your Qase Test run will look like:

Syntax

changelog: testng

For the most up-to-date changelog, please check our GitHub repository.