test_cases_create
Create test cases for meloQA projects, specifying steps, expected results, and custom fields.
Instructions
Create test case
Tag: Test Cases
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | Test case type ID — use GET /v1/test-case-types | |
| order | No | ||
| steps | No | Test case steps. The required shape depends on the test case type — list the available types and their IDs via `GET /v1/test-case-types` and pass the chosen `id` as `type` in the body. The four built-in types behave as follows: - **BDD**: at least 1 step required. Each step has `description` (required), `gherkinKeyword` (optional, defaults to `given`), and `data` (optional). `expectedResult` on the step is rejected — the BDD outcome is expressed by the `then` keyword. - **EXPECTED_RESULT_PER_STEP**: at least 1 step required. Each step has `description` and `expectedResult` (both required); `data` is optional. `gherkinKeyword` is rejected. - **GENERAL_EXEPECTED_RESULT**: steps are optional. When provided, each step has `description` (required) and `data` (optional). `expectedResult` on the test case (top-level) is required. - **NO_STEP**: steps are rejected. `expectedResult` on the test case is required. On `POST` the steps are created with the new test case. On `PATCH` sending `steps` replaces the existing list (soft-deletes old steps and creates new ones). Omit `steps` from the body to leave them untouched. | |
| folderId | No | ||
| scenario | No | ||
| statusId | Yes | Test case status ID — use GET /v1/test-case-statuses | |
| automated | No | Estado de automatização exibido na UI. Se omitido, é derivado de `automation` (AUTOMATED→YES, senão NO). | |
| projectId | Yes | ||
| automation | No | ||
| bddRawText | No | ||
| description | No | ||
| customFields | No | Values for the project's custom fields. Discover the available fields and their `id`s via `GET /v1/projects/{projectId}/test-case-custom-fields`. Each item targets one custom field by `projectCustomFieldId`. Send **`value`** for free-form fields (text, number, …) or **`selectId`** for select-type fields (must reference one of `selects[].id` returned by the listing endpoint). Exactly one of `value`/`selectId` must be provided per item. On `POST` the items create the values for the new test case. On `PATCH` each item is upserted by `(testCaseId, projectCustomFieldId)`: existing values are replaced, missing fields are created, and fields not mentioned in the array are left untouched. **Required fields rule:** every project custom field with `isRequired: true` and `isEnabled: true` must end up with a value. On `POST` they must be present in this array; on `PATCH` they must be either present here or already filled on the test case (otherwise the request is rejected with 400). **Disabled fields:** entries that target a custom field with `isEnabled: false` are silently ignored — the field is no longer in use, so the value is neither persisted nor counted toward the required-field rule. | |
| expectedResult | No | ||
| preRequirements | No | ||
| specificationTime | No | ||
| automatizationTime | No |