Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -26,21 +26,77 @@ contextual_links:

---

In Testsigma, you can check whether the Rest API is functioning correctly by adding verification and assertions. This involves testing the API endpoints, the data returned, and the response codes. Verification also includes validating the API against the requirements and ensuring that the API is secure. For verification, you need to add an API request and click **Create** to check the response. At the bottom of the screen, you can see the response and add verification. There are some steps to adding verification.
In Testsigma, you can validate whether a REST API is functioning correctly by adding verifications (assertions). These help ensure that the API response matches the expected status, headers, and body content.

**To add verification:**
- Send an API request.
- Review the response at the bottom of the screen.
- Click **Create** and add verification from the **Verification** tab.

---

## **Verification Types**

These types of verification are available for JSON and XML:
Verification types define how the response (JSON/XML) is compared with the expected value.

**1. Strict**
- Exact match required
- No extra fields allowed
- Array order must match

**2. Strict Order**
- Same as Strict
- Field order must also match

**3. Lenient (Recommended)**
- Validates only specified fields
- Extra fields allowed
- Order ignored

**4. Non Extensible**
- No extra fields allowed
- Order ignored

**5. Schema**
- Validates structure and data types, not exact values
Comment on lines +60 to +61
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Expand the Schema verification type description.

The Schema type description is notably brief compared to other verification types (1 line vs 3-4 bullet points). It doesn't clarify:

  • What "structure" validation means
  • When extra fields are allowed (referenced as "Depends" in the Quick Summary table)
  • How it differs from the other types in practical usage

Consider adding bullet points similar to other types for consistency and clarity.

📝 Suggested expansion
 **5. Schema**
-- Validates structure and data types, not exact values
+- Validates structure and data types, not exact values
+- Checks field types match the expected schema
+- Whether extra fields are allowed depends on schema definition
+- Useful for validating data shape without checking specific content
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
**5. Schema**
- Validates structure and data types, not exact values
**5. Schema**
- Validates structure and data types, not exact values
- Checks field types match the expected schema
- Whether extra fields are allowed depends on schema definition
- Useful for validating data shape without checking specific content
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/pages/docs/test-cases/create-steps-restapi/verifications-request.md`
around lines 60 - 61, Expand the "5. Schema" verification description under the
"Schema" heading to match other types: add 3–4 concise bullet points clarifying
(1) that "structure" means required keys and their data types are validated
(shape/schema, nested objects and arrays), (2) how extra fields are handled
(explicitly state when extra fields are allowed vs rejected and tie to the
"Depends" note), (3) typical use cases and how Schema differs from
Exact/Contains (validates shape and types, not exact values or presence-only
checks), and (4) a brief note about validation behavior for optional vs required
fields and nested structures so readers can apply it consistently.


### **Quick Summary**

| Type | Extra Fields Allowed | Order Check | Value Validation |
|------------------|--------------------|--------------|-------------------------------|
| **Strict** | ❌ No | Arrays only | Exact match required |
| **Strict Order** | ❌ No | ✔ Full order | Exact match required |
| **Lenient** | ✔ Yes | ❌ No | Only specified fields checked |
| **Non Extensible**| ❌ No | ❌ No | Exact match required |
| **Schema** | Depends | ❌ No | Structure & type validation |

> <p id="prerequisites">💡 Tip:</p>
> Use Lenient for most APIs with dynamic fields.

### **For Example:**

**Expected:**

```
{
"name": "Ganesh"
}
```
Comment on lines +80 to +84
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Add language identifier to code block.

The code block is missing a language identifier, which reduces syntax highlighting and accessibility. As per static analysis tools, fenced code blocks should specify the language.

🎨 Proposed fix
-```
+```json
 {
   "name": "Ganesh"
 }
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
```
{
"name": "Ganesh"
}
```
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)

[warning] 80-80: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/pages/docs/test-cases/create-steps-restapi/verifications-request.md`
around lines 80 - 84, The fenced code block in the Markdown file (the JSON
example under create-steps-restapi/verifications-request.md) lacks a language
identifier; update the triple-backtick fence to include "json" (i.e., ```json)
so the snippet is syntax-highlighted and passes static analysis for fenced code
blocks.


**Response:**

```
{
"name": "Ganesh",
"age": 30,
"city": "Bangalore"
}
```
Comment on lines +88 to +94
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Add language identifier to code block.

The code block is missing a language identifier, which reduces syntax highlighting and accessibility. As per static analysis tools, fenced code blocks should specify the language.

🎨 Proposed fix
-```
+```json
 {
   "name": "Ganesh",
   "age": 30,
   "city": "Bangalore"
 }
🧰 Tools
🪛 markdownlint-cli2 (0.21.0)

[warning] 88-88: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/pages/docs/test-cases/create-steps-restapi/verifications-request.md`
around lines 88 - 94, The fenced code block that currently contains the JSON
object with "name": "Ganesh", "age": 30, "city": "Bangalore" should include a
language identifier; update the opening fence from ``` to ```json so the block
reads as a JSON code block (ensuring proper syntax highlighting and satisfying
the static analysis requirement).


In this case,
- **Lenient:** Passes as it validates only the specified field (**name**) and ignores extra fields.

|Verification Types|Function|
| :----: | :----: |
| **Strict** | In strict verification, all conditions and rules must be met exactly as specified. If any requirements are met, the verification will succeed.|
| **Strict Order** | In strict order verification, the conditions and rules must be met in the specified order. The verification will only succeed if any requirement is met or is in order. |
| **Lenient** | In lenient verification, some conditions and rules may be ignored or relaxed, and the verification will still pass as long as the essential requirements are met.|
| **Non-extensible** | In non-extensible verification, the verification rules cannot be modified or extended. Only the pre-defined rules can be applied. |
| **Schema** | A schema is a set of rules defining data or documents' structure, format, and constraints. It can validate, verify, or transform data in different contexts, such as databases, APIs, or file formats. |
- **Strict:** Fails as extra fields (**age**, **city**) are not allowed.

---

Expand Down
Loading