npm - testeiya - Versions diffs - 0.2.1 → 0.3.9 - Mend

testeiya 0.2.1 → 0.3.9

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (414) hide show

package/skills/testomatio/test-management/qa-write-test-cases/SKILL.md DELETED Viewed

@@ -1,267 +0,0 @@
----
-name: qa-write-test-cases
-description: Generate test cases and checklists for software testing. Use this skill whenever the user asks to create test cases, test scenarios, test plans, checklists, QA documentation, or mentions testing activities like "write tests for feature", "create a test checklist", "generate test scenarios from requirements", or similar. This skill works better if user provides documentation, requirements, etc., or it can create test cases based on the user prompt without any additional context.
----
-# Test Case & Checklist Generator
-Generates test cases and checklists for software testing from the context the user provides.
-References:
-- [Test Case Format](./references/test-case-format.md) — markdown format for suites, tests, and steps (Testomat.io-friendly)
-- [Writing Rules](./references/writing-rule.md) — rules for suites, tests, preconditions, steps, and AI writing patterns to avoid
-- [Testomat.io TMS Guide](./references/testomat-tms-guide.md) — Testomat.io conventions and MCP tools
-## Prerequisites
-- Project structure checked (source code, e2e tests, test cases) via the /scan-automation-project skill.
-- Existing Testomat.io tests pulled via the /sync-test-cases-with-tms skill.
-- PLAN mode enabled, if available, for the interview steps.
-## User interaction
-- **Always generate a checklist before test cases**, even if the user asks for test cases directly.
-- **Do not skip steps. Get user approval at each gate before moving to the next step.**
-- Strictly recommend PLAN mode. Switch to Edit mode only on the last step — writing test cases to md files.
-- Use the Ask tool for choices when available.
-- Fill input fields with suggestions when asking the user for input.
-- Mark questions with ❓ and numbered options:
-```
-❓ Do you want to:
-1. action 1
-2. action 2
-3. type something else
-```
-## Workflow
-1. Gather context and show sources — approval gate
-2. Ask for coverage scope — approval gate
-3. Ask for role — approval gate; skipped for smoke
-4. Generate checklist — approval gate
-5. Generate detailed test cases
-6. Show summary
-### Step 1: Gather context
-Understand:
-- the feature/functionality under test and its business goals
-- main testing flows and user journeys
-- specific areas of concern
-Information sources:
-- User prompt
-- Task tracking systems (Jira, etc.)
-- Requirements documents (Confluence, etc.)
-- Design mockups (Figma, Miro, etc.)
-- Existing test cases (TestRail, Testomat.io, etc.)
-- Source code:
-  - manual test files: `.test.md` or `.md` in folders like `manual-tests`, `tests`, `manual`, `qa`, `spec`
-  - automated test files (spec, test, cy files, etc.)
-  - project structure
-Sources may come as pasted text, links, or MCP tools. Ask the user for MCP configuration if needed.
-Analyzing source code:
-- Usually this skill runs from an automation project without application code. Check which case this is.
-- Automation-only project: scan briefly, focus on test files.
-- Application + automation project: scan the application code thoroughly; skip unit-test depth unless the user asks.
-#### Testomat.io TMS detection
-Detect if this is a Testomat.io project. Two options:
-Option 1 — MCP. If the `testomatio` MCP is available, gather context:
-- `suites_list`, `suites_search` — existing structure
-- `tests_search`, `tests_list` — existing tests, avoid duplicates
-- `steps_list`, `steps_search` — reusable shared steps
-- `tags_list`, `labels_list` — project conventions
-Option 2 — `sync-test-cases-with-tms` skill (with `check-tests` lib). Run it with the `pull` action, then analyze the downloaded files for:
-- existing structure and suites
-- current test cases (to avoid duplicates)
-- project conventions (tags, labels, priority levels)
-If existing test cases intersect with the feature under test, report them to the user and suggest expanding them or creating a new suite.
-#### Approval gate
-Show the list of sources (names only, no content) and ask:
-```markdown
-I've gathered information from the following sources:
-- Jira issue ABC-123
-- Confluence
-- Figma
-❓ Do you want to:
-1. ➡️ Go to next step
-2. ✏️ Type changes
-```
-### Step 2: Ask for coverage scope
-The scope sets the initial checklist size; the user can still fine-tune it in Step 4.
-- **Compute approximate test counts per tier from your Step 1 analysis. Do not use generic or hardcoded ranges** — the numbers must reflect the specific feature under test.
-- If you can't reasonably estimate (feature too vague, context too thin), say so and either omit the numbers or go back to Step 1.
-- If the user picks ✏️ Other, accept a number ("around 10") or a free-form description ("just the API contract, no UI") and size the checklist from it.
-Show each option as a block: bold label with test count on the first line, description on the next. Replace `<N>` with your estimates:
-```markdown
-❓ **How much coverage do you want?**
-**1. 🚀 Smoke** ~<N> tests
-Critical-path only
-**2. ⚖️ Balanced** ~<N> tests
-Happy path, key negative and common edge cases
-**3. 🧨 Exhaustive** ~<N> tests
-Full coverage incl. error states, boundaries, and security/perf/i18n where relevant
-**4. ✏️ Other**
-Proceed to specific role selection, type a number of tests, or describe scope in your own words
-```
-### Step 3: Ask for role
-- If the user picked 🚀 Smoke in Step 2: **skip this step** — auto-apply ⚙️ default and go straight to Step 4. A smoke suite is too small to benefit from a specialized role.
-- Otherwise show the roles (markdown table with name and short description) and ask the user to pick one. Recommend a role based on context.
-- Use ⚙️ default if the user does not specify a role.
-- If the user selects 🔧 other, ask them to define a custom role.
-- If you show only some roles, add a "Show all available roles" option:
-```
-❓ Choose role:
-1. default (or recommended role based on context)
-2. ☰ Show all available roles
-3. ✏️ Type role name
-```
-#### Roles
-| Role               | Description                              |
-| ------------------ | ---------------------------------------- |
-| **⚙️ default**     | **balanced** approach                    |
-| **🌈 optimist**    | **positive** flows, happy path           |
-| **🤓 nerd**        | **details**, dependencies, perfectionist |
-| **🔪 psycho**      | **edge cases**                           |
-| **🔐 pentest**     | **security**                             |
-| **🎨 picasso**     | **ui/ux**                                |
-| **⚖️ lawyer**      | **texts**, error messages, typos, etc.   |
-| **🌐 polyglot**    | **localization**, translations           |
-| **📈 performance** | **performance**, load, stress, etc.      |
-| 🔧 other           | **specify your own role**                |
-### Step 4: Generate checklist
-Create a hierarchical, categorized checklist from the gathered context.
-Size it to the Step 2 tier:
-- 🚀 smoke — only critical paths
-- ⚖️ balanced — happy path, key negative, common edge cases
-- 🧨 exhaustive — full coverage
-- ✏️ other — follow what the user described
-Example:
-```markdown
-- Signup
-  - Signup with valid email
-  - Signup with valid phone number
-- Login
-  - Login with valid email
-  - Login with valid phone number
-  - Login with invalid password
-```
-#### Approval gate
-- If a multi-select/checkbox Ask tool is available: present leaf items as checkboxes, prefixed with their category (e.g. `Login: valid email`), with the recommended subset for the chosen tier pre-checked. The ticked items become the test cases in Step 5.
-- Otherwise: show the markdown checklist and ask the user to add/remove/change items.
-Always ask about the amount of cases / level of detail:
-```
-❓ Do you want to:
-1. 👍 Keep as is
-2. ➖ Less details
-3. ➕ More details
-4. ✏️ Type anything you want to change
-```
-- More details → enable the 🤓 nerd role.
-- User modifies the checklist → regenerate (Step 4).
-- User not satisfied → go back to Step 1 for more context.
-- Approved → Step 5.
-### Step 5: Generate detailed test cases
-If the user originally asked only for a checklist, first ask: "Do you want to generate test cases for this checklist?"
-Where to store test cases:
-- Empty or manual-tests-only workspace → project root
-- End-to-end testing project → `manual-tests/` directory
-- Any other case → `.testeiya/manual-tests/` (ensure `.testeiya/` exists and is git-ignored)
-Generation rules:
-- Name files `feature-name.test.md` (always the `.test.md` extension).
-- Multiple features or whole product → one file per feature.
-- **Don't change the user's source code. Only generate `*.test.md` files.**
-- **Keep scope**: test only the functionality under test; don't test linked features unless the user explicitly asks.
-Format rules:
-- Strictly follow [Test Case Format](./references/test-case-format.md) for suites, tests, and steps. Only exception: the user specifies their own format in the prompt.
-- Strictly follow [Writing Rules](./references/writing-rule.md) for suite/test descriptions, preconditions, steps, expected results, and anti-patterns.
-- Follow the [Testomat.io TMS Guide](./references/testomat-tms-guide.md) for conventions (priority levels, tags, labels), especially when using the testomatio MCP.
-- Wrap test cases in `<!-- suite ... -->` and `<!-- test ... -->` blocks.
-- If required, put `tags:` and `labels:` inside each `<!-- test ... -->` metadata block (see [test metadata](./references/test-case-format.md#test-metadata)), not only on the suite block.
-- Reuse existing tags and labels obtained via MCP or from other test cases.
-- Do not use labels if you are not aware of any existing ones.
-- If reasonable, add test metadata (priority, preconditions, test data, labels, tags) based on the analyzed context.
-- Use concrete, executable values. **Do NOT introduce `${...}` placeholders in first-pass generation.** Parametrize only genuinely reused or data-driven values; format them as `${variable}` in backticks.
-- **NEVER generate test or suite IDs of any kind:**
-  - Do NOT include Testomat.io IDs (`id: @T*`, `id: @S*`, e.g. `@T12345678`, `@S380c64db`).
-  - Do NOT include custom/random IDs (e.g. `TC-001`, `TC-R001`, `SUITE-01`) in `id:` fields, titles, or anywhere else.
-  - Testomat.io IDs are server-generated and assigned when the user runs `check-tests push` with `--update-ids` (or via the `sync-test-cases-with-tms` skill). Never add IDs at generation time.
-#### Matching existing test case formats
-When the user provides an existing test case example or asks for "similar" test cases:
-DO match:
-- writing style and level of detail
-- field structure (Priority, Preconditions, Type, Test Data, etc.)
-- additional fields like labels and tags
-- original case language
-DON'T copy:
-- any IDs from the example — neither Testomat.io IDs (`@T...`, `@S...`) nor custom prefixes (e.g. `TC-R001`, `TC-001`)
-- original test case intent
-### Step 6: Show summary
-- Show a concise summary (markdown table works well): number of test cases and suites, generated files, destination folder.
-- Ask the user to review the files and request changes if needed.
-- Suggest uploading the test cases to Testomat.io via the `sync-test-cases-with-tms` skill.

package/skills/testomatio/test-management/qa-write-test-cases/references/test-case-format.md DELETED Viewed

@@ -1,387 +0,0 @@
----
-title: Classical Tests Markdown Format
-description: Complete reference for the Testomat.io classical tests Markdown format. Learn the structure, metadata fields, and formatting rules for test suites and test cases.
----
-# Classical Tests Markdown Format
-## Format Overview
-The document is structured as:
-1. **Suite block** — one per file, with suite metadata and content
-2. **Test blocks** — one or more, each with test metadata and content
-3. **Examples section** (optional) — parametrized test data in a markdown table
----
-## Document Structure
-```
-<!-- suite
-key: value
--->
-# Suite Title
-Suite description (optional)
-<!-- test
-key: value
--->
-# Test Title
-Test description (optional)
-<!-- example -->
-| Param1 | Param2 |
-| --- | --- |
-| value1 | value2 |
-```
----
-## Suite Metadata
-Metadata is inside an HTML comment block: `<!-- suite ... -->`.
-| Field      | Type   | Description                                                                                        |
-| ---------- | ------ | -------------------------------------------------------------------------------------------------- |
-| `id`       | string | **Required.** Suite UID in format `@S{uid}` 8-chars (e.g. `@S380c64db`). Used for sync and import. |
-| `emoji`    | string | Emoji for the suite (e.g. `🙂`, `🔐`).                                                             |
-| `tags`     | string | Comma-separated tags not in the title (e.g. `smoke, regression`).                                  |
-| `labels`   | string | Comma-separated labels in `Label: value` or `Label` format (e.g. `Priority:High, Component:Auth`). |
-| `assignee` | string | User email for the assignee. Must exist in the project.                                            |
----
-## Test Metadata
-Metadata is inside an HTML comment block: `<!-- test ... -->`.
-| Field      | Type    | Description                                                                                           |
-| ---------- | ------- | ----------------------------------------------------------------------------------------------------- |
-| `id`       | string  | Test UID in format `@T{uid}` 8-chars (e.g. `@T12345678`). Optional; used for matching existing tests. |
-| `type`     | string  | Test state: `manual` or `automated`.                                                                  |
-| `priority` | string  | One of: `low`, `normal`, `important`, `high`, `critical`.                                             |
-| `assignee` | string  | User email for the assignee. Must exist in the project.                                               |
-| `creator`  | string  | User email for the creator (used when `include_meta: [:creator]`).                                    |
-| `shared`   | boolean | `true` when the test is shared (used when `include_meta: [:shared]`).                                 |
-| `tags`     | string  | Comma-separated tags not in the title.                                                                |
-| `labels`   | string  | Comma-separated labels in `Label: value` or `Label` format.                                           |
-If the test has no assignee but the suite does, the suite assignee is used.
----
-## Formatting Rules
-### 1. Metadata blocks
-- Metadata must be inside HTML comments: `<!-- suite ... -->` and `<!-- test ... -->`.
-- Each line is `key: value`; lines without `:` are ignored.
-- Keys and values are trimmed of surrounding whitespace.
-### 2. Headings
-- **Suite title:** first `#` heading after the suite metadata block.
-- **Test title:** first `#` or `##` heading after each test metadata block.
-- Only these headings are used for titles; other headings are part of the description.
-### 3. Suite and test blocks
-- Suite block starts with `<!-- suite`.
-- Test blocks start with `<!-- test`.
-- Each test block is separated by `<!-- test`; the parser splits on `(?=<!--\s*test\b)`.
-### 4. Examples section
-- Introduced by `<!-- example -->` (optional content after `-->`).
-- Must be a markdown table.
-- **Table format:** rows must start with `| ` and end with ` |`.
-- **Headers:** first row after `<!-- example -->` is header.
-- **Separator:** next row must contain `---` (3+ dashes) in each cell to mark headers.
-- **Data rows:** rows after the separator are example rows.
-- **Params:** if a separator row exists, the row above it is used as `params` (column names).
-- **No params:** if there is no separator row, all rows are data rows.
-### 5. Tags
-- In title: `@tag` format (e.g. `Test @smoke @regression`).
-- In metadata: comma-separated without `@` (e.g. `tags: smoke, regression`).
-- Valid tag characters: `\w`, `\d`, `=`, `-`, `_`, `()`, `.`, `:`, `&`, length < 120.
-- Tags in metadata must not include suite/test IDs (`@S...`, `@T...`).
-### 6. Labels
-- Format: `LabelTitle` or `LabelTitle: value`.
-- Labels are matched by title or slug in the project.
-- Labels with values use `:` as separator.
-### 7. Attachments
-- All attached items as links: `https://app.testomat.io/attachments/{uid}.{ext}`
-### 8. Description
-- Everything after the test heading until the next `<!-- test` or `<!-- example` is the test description.
-- Description supports standard markdown.
-### 9. Test Steps Format
-Test steps use the `## Steps` header section with a nested markdown list format:
-```markdown
-## Steps
-- (Step Action)
-  *Expected*: ... (Observable behavior)
-- ...
-  *Expected*: ...
-```
-**Step format rules:**
-- Steps must be under a `## Steps` heading
-- Use nested markdown lists (bulleted `*` or numbered `1.`)
-- Top-level items describe the action to perform
-- Nested items with `*Expected*` (or `*Expected*:`, `*Expected result*`) describe the observable behavior
-- Expected results should be specific and verifiable
----
-## Examples
-### Minimal suite with one test
-```markdown
-<!-- suite
-id: @S12345678
--->
-# Login Suite
-Tests for login functionality.
-<!-- test
--->
-# Successful Login
-User can log in with valid credentials.
-```
-### Full suite with metadata and examples
-```markdown
-<!-- suite
-id: @S380c64db
-emoji: 🔐
-tags: smoke, regression
-assignee: qa@example.com
--->
-# Login Functionality
-This suite contains manual tests for the login process.
-<!-- test
-id: @T12345678
-type: manual
-priority: high
-assignee: qa@example.com
-tags: critical
--->
-# Successful Login
-A user should be able to log in with valid credentials.
-## Steps
-- Navigate to the login page
-  *Expected*: Login form is displayed with username and password fields
-- Enter a valid username and password
-  *Expected*: Credentials are entered without errors
-- Click the "Login" button
-  *Expected*: User is redirected to the dashboard
-<!-- example -->
-| Username | Password | Role  |
-| -------- | -------- | ----- |
-| admin    | admin123 | admin |
-| user     | user123  | user  |
-```
-### Test with proper step format
-```markdown
-<!-- suite
-id: @S11111111
--->
-# User Registration
-Tests for user registration functionality.
-<!-- test
-id: @T22222222
-type: manual
-priority: high
--->
-# Register new user with valid data
-Verify that a new user can successfully register with valid information.
-## Steps
-- Navigate to the registration page
-  *Expected*: Registration form is displayed
-- Enter a valid email address
-  *Expected*: Email is accepted and passes validation
-- Enter a strong password (8+ characters with uppercase, lowercase, and numbers)
-  *Expected*: Password meets complexity requirements
-- Confirm the password
-  *Expected*: Passwords match
-- Accept the Terms of Service
-  *Expected*: Checkbox is selected
-- Click the "Register" button
-  *Expected*: Success message is displayed and user is redirected to welcome page
-```
-### Test with numbered steps
-```markdown
-<!-- suite
-id: @S33333333
--->
-# API Testing
-Tests for REST API endpoints.
-<!-- test
-id: @T44444444
-type: automated
-priority: critical
--->
-# Create new user via API
-Verify that a new user can be created via POST request.
-## Steps
-1. Send POST request to `/api/users` with valid user data
-   *Expected*: Response status code is 201
-2. Verify response contains user ID and created timestamp
-   *Expected*: Response includes `id` and `createdAt` fields
-3. Send GET request to `/api/users/{id}` to retrieve the created user
-   *Expected*: User data matches the data sent in POST request
-```
-### Test with complex nested steps
-```markdown
-<!-- suite
-id: @S55555555
-emoji: 🛒
--->
-# E-commerce Checkout
-Tests for the checkout process.
-<!-- test
-id: @T66666666
-type: manual
-priority: high
--->
-# Complete checkout with multiple items
-Verify that a user can complete the checkout process with multiple items in the cart.
-## Steps
-- Add multiple products to the cart
-  *Expected*: All products appear in the cart with correct quantities and prices
-- Proceed to checkout
-  *Expected*: Checkout page loads with shipping address form
-- Fill in valid shipping address details
-  *Expected*: Form validation passes and shows no errors
-- Select a shipping method
-  *Expected*: Shipping cost is calculated and displayed
-- Select a payment method
-  *Expected*: Payment form is displayed (or guest checkout option)
-- Complete the payment process
-  *Expected*: Payment is processed successfully
-- Verify order confirmation
-  *Expected*: Order confirmation page is displayed with order number and summary
-- Check email for order confirmation
-  *Expected*: Confirmation email is received with matching order details
-```
-### Test with tags in title
-```markdown
-<!-- test
--->
-# API test with multiple endpoints @smoke @regression
-Test API endpoints with different parameters
-<!-- example -->
-| Endpoint | Method | Status |
-| -------- | ------ | ------ |
-| /users   | GET    | 200    |
-| /posts   | POST   | 201    |
-```
-### Examples without params (no header row)
-```markdown
-<!-- test
--->
-# Test with Examples No Params
-Test description
-<!-- example
--->
-| Value1 | Value2 |
-```
-### Multiple suites in one file
-```markdown
-<!-- suite
-id: @S12345678
--->
-# Suite One
-Description for suite one
-<!-- test
-id: @Ta1b2c3d4
--->
-# Test One
-Description
-<!-- suite
-id: @S98765432
--->
-# Suite Two
-Description for suite two
-```