testeiya 0.2.1 → 0.3.9

package/skills/testomatio/test-automation/testomat-allure-adapter/SKILL.md

@@ -1,289 +0,0 @@
----
-name: Testomat Allure Adapter Setup
-description: Configure Testomat.io reporting for Java projects that already use Allure. Ask the user whether they want to keep existing Allure annotations and only add Testomat.io reporting or replace Allure annotations with native Testomat.io annotations. If they keep Allure add the testomat-allure-adapter dependency for Maven or Gradle.
-required_action: true
----
-
-# Testomat Allure Adapter
-
-Configure Testomat.io reporting for Java projects that already use Allure. Two modes: keep Allure and add the adapter, or migrate to native Testomat.io annotations.
-
-Before configuring the project, ask the user which mode they want:
-
-> Do you want to keep your existing Allure annotations and use Testomat.io only for reporting test results, or would you like to replace Allure annotations with Testomat.io annotations?
-
-## Option 1: Keep Allure and Report to Testomat.io
-
-Use this option if:
-
-* The project already uses Allure annotations.
-* The user wants to keep annotations such as `@Epic`, `@Feature`, `@Story`, `@Owner`, `@Severity`.
-
-**The adapter only transfers data from Allure to Testomat.io. It does not migrate, generate, or synchronize annotations from Testomat.io back to Allure.**
-
-Install the Testomat Allure Adapter.
-
-### Maven
-
-```xml
-<dependency>
-    <groupId>io.testomat</groupId>
-    <artifactId>testomat-allure-adapter</artifactId>
-    <version><LATEST_STABLE_VERSION></version>
-</dependency>
-```
-
-### Gradle
-
-```gradle
-implementation 'io.testomat:testomat-allure-adapter:<LATEST_STABLE_VERSION>'
-```
-
-## Option 2: Migrate from Allure to Testomat.io
-
-Use this option if:
-
-* The user wants to stop using Allure annotations.
-* The user wants Testomat.io annotations and reporting only.
-* The project is new or a migration is planned.
-
-Migrate the project to the standard Testomat.io reporter.
-
-**Remove Allure dependencies only when both conditions hold:**
-
-1. The user explicitly chose to remove unsupported Allure annotations.
-2. No Allure annotations, APIs, listeners, or reporting integrations remain in the project.
-
-### Supported Replacements
-
-Apply these automatically:
-
-```text
-@DisplayName → @Title (automatic)
-@AllureId → @TestId (automatic)
-@TmsLink → @TestId (automatic)
-@Attachment → @Artifact (automatic)
-@Step → @Step (automatic)
-```
-
-### Unsupported Allure Annotations
-
-All other Allure annotations (`@Epic`, `@Feature`, `@Story`, `@Owner`, `@Severity`, `@Description`, `@Issue`, etc.) have no Testomat.io equivalent. **Never migrate, replace, or remove them automatically.**
-
-If any are detected, ask:
-
-> Unsupported Allure annotations were found. Testomat.io currently does not provide direct replacements for these annotations. Would you like to keep them or remove them?
-
-If the user keeps them:
-
-* Leave the annotations, Allure dependencies, and Allure configuration intact.
-
-If the user removes them:
-
-* Remove the unsupported annotations.
-* Continue migration using only supported Testomat.io annotations.
-* Remove Allure dependencies only per the conditions above.
-
-### Replace @DisplayName
-
-```java
-@DisplayName("Login test")
-```
-↓
-```java
-@Title("Login test")
-```
-
-```java
-import org.junit.jupiter.api.DisplayName;
-```
-↓
-```java
-import io.testomat.core.annotation.Title;
-```
-
-### Replace @AllureId
-
-```java
-@AllureId("a1b2c3d4")
-```
-↓
-```java
-@TestId("a1b2c3d4")
-```
-
-```java
-import io.qameta.allure.AllureId;
-```
-↓
-```java
-import io.testomat.core.annotation.TestId;
-```
-
-### Replace @TmsLink
-
-```java
-@TmsLink("k8m2x9q1")
-```
-↓
-```java
-@TestId("k8m2x9q1")
-```
-
-```java
-import io.qameta.allure.TmsLink;
-```
-↓
-```java
-import io.testomat.core.annotation.TestId;
-```
-
-### @AllureId and @TmsLink Conflict
-
-If both are present on the same test:
-
-* **Do not replace automatically.**
-* Both map to `@TestId`, and Testomat.io supports only one `@TestId` per test.
-* Ask the user which value to use.
-
-### Replace @Step
-
-```java
-import io.qameta.allure.Step;
-```
-↓
-```java
-import io.testomat.core.annotation.Step;
-```
-
-```java
-@io.qameta.allure.Step
-```
-↓
-```java
-@io.testomat.core.annotation.Step
-```
-
-### Replace @Attachment
-
-```java
-import io.qameta.allure.Attachment;
-```
-↓
-```java
-import io.testomat.core.annotation.Artifact;
-```
-
-```java
-@Attachment
-```
-↓
-```java
-@Artifact
-```
-
-### Replace Allure.step
-
-Analyze all detected `Allure.step(...)` overloads before replacing anything.
-
-Supported replacements:
-
-```java
-Allure.step(String name)
-```
-↓
-```java
-Testomatio.step(String name, () -> {})
-```
-
-```java
-Allure.step(String name, Status status)
-```
-↓
-```java
-Testomatio.step(String name, () -> {})
-```
-The `Status` value is dropped: `Testomatio.step(...)` does not support step status overrides.
-
-```java
-Allure.step(ThrowableContextRunnableVoid<StepContext> runnable)
-```
-↓
-```java
-Testomatio.step("", () -> { /* original runnable body */ })
-```
-
-```java
-Allure.step(String name, ThrowableContextRunnableVoid<StepContext> runnable)
-```
-↓
-```java
-Testomatio.step(String name, () -> { /* original runnable body */ })
-```
-
-```java
-Allure.step(String name, ThrowableRunnableVoid runnable)
-```
-↓
-```java
-Testomatio.step(String name, () -> { /* original runnable body */ })
-```
-
-Rules:
-
-* Preserve the original step name whenever available.
-* Move the original runnable body into the `Runnable` argument of `Testomatio.step(...)`.
-
-Overloads that return a value are NOT supported, because `Testomatio.step(String stepDescription, Runnable function)` does not return a value:
-
-```java
-Allure.step(String name, ThrowableRunnable<T> runnable)
-```
-
-```java
-Allure.step(ThrowableContextRunnable<T, StepContext> runnable)
-```
-
-```java
-Allure.step(String name, ThrowableContextRunnable<T, StepContext> runnable)
-```
-
-If return-value overloads are detected, ask:
-
-> Some Allure.step(...) usages return a value and cannot be migrated automatically because Testomatio.step(...) does not support return values. How would you like to proceed?
-
-Options:
-
-1. Replace supported overloads and keep unsupported overloads unchanged.
-2. Skip Allure.step migration entirely and keep all existing usages.
-
-If the user chooses option 1:
-
-* Replace supported overloads.
-* Leave return-value overloads unchanged.
-* Inform the user which usages require manual migration.
-
-If the user chooses option 2:
-
-* Leave all `Allure.step(...)` usages unchanged.
-
-**While any `Allure.step(...)` usages remain, keep Allure dependencies in the project.**
-
-### Replace Allure.addAttachment
-
-* Inside a step, replace with `Testomatio.stepArtifact(String pathToFile)`.
-* Outside a step, replace with `Testomatio.artifact(String pathToFile)`.
-
-### Required Maven Surefire Plugin Configuration
-
-Always check the Maven Surefire Plugin configuration. If the project uses it:
-
-* If no `argLine` is configured, add the AspectJ javaagent using the version declared in the project's dependencies.
-* If an `argLine` exists, preserve the existing value and append the javaagent. **Do not overwrite or remove existing JVM arguments.**
-* If the AspectJ version cannot be determined, ask the user before adding the javaagent.
-
-```xml
-<argLine>
-    -javaagent:"${settings.localRepository}/org/aspectj/aspectjweaver/${aspectj.version}/aspectjweaver-${aspectj.version}.jar"
-</argLine>
-```

package/skills/testomatio/test-management/detect-duplicate-test-cases/SKILL.md

@@ -1,86 +0,0 @@
----
-name: detect-duplicate-test-cases
-description: Find duplicate, near-duplicate, and overlapping test cases across the test suite. Identifies exact matches, semantically similar tests, and tests that are subsets of other tests. Provides recommendations for which tests to keep, merge, or remove.
----
-
-# Detect Duplicate Test Cases
-
-Detect duplicate test cases in the user's project. Recommend cleanup actions.
-
-## Workflow
-
-### 1. Collect Test Cases
-
-- Find all manual and automated test cases in the repository.
-  - Manual: markdown files inside `/tests/`, `.feature` files (Gherkin).
-  - Automated: `*.spec.ts`, `*.test.js`, `*.cy.js`, etc.
-- Parse each test to extract: title, steps, expected results, tags, and suite location.
-
-### 2. Analyze Duplicates
-
-Normalize test content before comparison:
-- Convert titles to lowercase.
-- Remove punctuation and formatting differences.
-- Normalize step wording where possible.
-- Ignore framework syntax (`describe`, `Scenario`, `it`, etc.) when analyzing intent.
-- Treat parameterized values (emails, IDs, usernames) as variable data.
-
-Compare tests using multiple similarity signals:
-- Title similarity.
-- Step similarity.
-- Expected result similarity.
-- Preconditions or setup.
-- Shared tags or metadata.
-- Test location or suite context.
-
-Score each pair using the scoring rules in `./references/DUPLICATE_INSTRUCTIONS.md`.
-Classify each pair into a detection level (defined in the same reference):
-- Level 1: exact duplicates.
-- Level 2: semantic duplicates.
-- Level 3: overlapping / subset tests.
-- Level 4: redundant variations.
-
-Build duplicate groups where multiple tests represent the same testing intent.
-Each group includes:
-- All related tests.
-- Similarity score.
-- Detection level.
-- Proposed canonical test.
-
-### 3. Generate Report
-
-Follow the report template in `./references/DUPLICATE_INSTRUCTIONS.md`. Include:
-- Summary statistics (total scanned, duplicates found by category).
-- Each duplicate group with test details and locations.
-- Similarity percentage.
-- Recommendation for each group (`keep`/`merge`/`remove`).
-- Suggested actions.
-
-### 4. Execute Actions
-
-**Apply actions only after the user approves the recommendations.**
-
-- Merge: combine duplicate or highly similar tests into one canonical test.
-  - Preserve the original test structure used by the framework (e.g., Gherkin, Markdown, Jest, Cypress).
-  - Retain the primary test ID from the canonical test.
-  - Merge tags, labels, and metadata from all source tests (deduplicate where possible).
-  - Preserve important assertions, steps, and expected results.
-  - Add references to the original test files or IDs that were merged.
-- Remove: delete duplicate or redundant test files or test entries.
-  - Ensure the canonical or replacement test already exists.
-  - Add a reference in the canonical test noting which tests were removed.
-  - **Do not remove tests that contain unique steps, tags, or coverage.**
-- Keep: keep both tests but document their relationship.
-  - Add cross-reference notes between related tests.
-  - Indicate the reason both tests remain (e.g., different environments, data sets, or coverage).
-
-## Preservation Rules
-
-When merging or rewriting tests, preserve:
-- Test IDs: keep the canonical ID and reference any merged IDs.
-- Tags / labels: retain and merge all relevant tags.
-- Framework structure: keep the original format (e.g., `Scenario`, `describe/it`, Markdown sections).
-- File organization: maintain the existing test directory conventions.
-- Traceability metadata: keep links to requirements, issues, or tickets if present.
-
-**Never break framework syntax or remove traceability metadata when rewriting tests.**

package/skills/testomatio/test-management/detect-duplicate-test-cases/references/DUPLICATE_INSTRUCTIONS.md

@@ -1,54 +0,0 @@
-# Duplicate Detection Guide
-
-Reference for scoring and classifying duplicate test cases.
-
-## Detection Levels
-
-| Level | Type | Description | Example |
-|-------|------|-------------|---------|
-| 1 | Exact Duplicates | Identical titles | "Verify login" appears in 3 files |
-| 2 | Semantic Duplicates | Same intent, similar steps | "Check user can sign in" vs "Validate user authentication" |
-| 3 | Overlapping / Subset | One test contains another | Cart test (3 steps) inside Checkout test (8 steps) |
-| 4 | Redundant Variations | Same logic, different data | Login with john@example.com vs jane@example.com |
-
-## Similarity Scoring
-
-Compare test pairs on: title -> steps -> expected results -> preconditions -> tags.
-
-| Score | Category |
-|-------|----------|
-| 100% | Exact duplicate |
-| 80-99% | Semantic duplicate |
-| 50-79% | Overlapping |
-| <50% | Different tests |
-
-For automated tests, also consider code-level duplicates in assertions and shared setup/teardown.
-
-## Actions
-
-| Action | When to Use |
-|--------|-------------|
-| Merge | Tests duplicate the same intent — combine into one canonical test |
-| Remove | One test is redundant — keep the more complete one |
-| Keep | Tests serve different purposes (different environments, data, coverage) |
-
-## Report Template
-
-```markdown
-# Duplicate Analysis Report
-
-**Scanned:** {N} tests across {M} files
-**Duplicates found:** {X} tests in {Y} groups
-
-## Summary
-- Exact: {N} groups | Semantic: {N} groups | Overlapping: {N} groups | Variations: {N}
-
-## Group {N}: {Type} — {Test Name}
-
-**Tests:**
-- `{file}` -> "{title}" ({id})
-- `{file}` -> "{title}" ({id})
-
-**Similarity:** {X}%
-**Recommendation:** {Keep / Merge / Remove}
-```

package/skills/testomatio/test-management/improve-test-cases/SKILL.md

@@ -1,114 +0,0 @@
----
-name: improve-test-cases
-description: Analyze and improve existing markdown manual test cases for clarity, structure, and Test Management Tool format compliance.
-license: MIT
-metadata:
-  author: Testomat.io
-  version: 1.0.0
----
-
-# Improve Test Cases
-
-Analyze and improve existing markdown manual test cases to make them clearer for the QA team:
-- Improve test titles for clarity.
-- Enhance test descriptions.
-- Fix broken formatting and markdown syntax.
-- Standardize test structure to Test Management Tool format.
-- Ensure consistent terminology and language.
-- Update tags and labels.
-
-**DO NOT CHANGE:**
-- Original test/suite IDs.
-- Original test intent.
-- Original language (fix only clarity, grammar, typos).
-
-## Step 1: Locate Test Files
-
-- Find markdown test files (`.test.md` or `.md`) in common locations: `./manual-tests`, `./tests/manual`, `./docs/tests`.
-- If none found, scan the whole project for `.md` files with test case content.
-- If still none, ask the user for the test directory path.
-
-## Step 2: Analyze Test Quality
-
-Read each test and flag issues:
-
-Titles:
-- Unclear or vague test title.
-- Missing action-object format.
-- Not specific enough to understand what is being tested.
-
-Descriptions:
-- Vague or unclear test purpose.
-- Missing or incomplete description.
-
-Steps and expected results:
-- Missing expected results.
-- Inconsistent step format.
-- Unclear actions.
-- Steps not ordered logically.
-- Expected results not relevant to the steps.
-- Missing pass/fail criteria.
-
-Formatting:
-- Broken markdown syntax.
-- Missing sections.
-- Inconsistent header hierarchy.
-
-Ambiguity:
-- Generic or subjective terms ("should work", "might fail").
-- Vague language that could be interpreted multiple ways.
-- Steps that cannot be verified objectively.
-- Missing specific values, data, or conditions.
-
-## Step 3: Show Summary to User
-
-- List issues found per test.
-- Give specific recommendations for improvements.
-- **Ask the user to confirm before proceeding.**
-- If the user does not confirm, do not change anything.
-
-## Step 4: Improve Tests
-
-Titles:
-- Make clear and specific.
-- Use action-result format: "Verify [action] results in [expected]".
-- Ensure the title reflects the actual test purpose.
-
-Descriptions:
-- Make purpose clear and concise.
-- Include context from the parent suite when relevant.
-- Fix grammar and spelling only.
-
-Steps:
-- Give each step an explicit expected result.
-  - Nested format: "- Step action..." with indented "_Expected_: ...".
-- Make actions specific and reproducible.
-- Add measurable pass/fail criteria.
-- Ensure results are directly relevant to the step action.
-- Make results measurable and verifiable.
-- Avoid vague terms; use specific values and conditions.
-
-Ambiguity:
-- Replace generic terms with specific, testable language.
-- Avoid subjective terms ("should work", "might fail").
-- Ensure steps can be verified objectively.
-
-Metadata:
-- Set `type: manual` in test metadata.
-- Use only these priority values: `low`, `normal`, `important`, `high`, `critical`.
-
-## Step 5: Save Changes
-
-- Overwrite the original files.
-- Keep the same file names and directory structure.
-- **Preserve all original test/suite IDs.**
-
-## Step 6: Show Final Summary
-
-- Number of files modified.
-- Number of tests improved.
-- Key improvements made.
-
-## Reference
-
-TMS markdown format example: [references/TESTOMAT_MARKDOWN_EXAMPLE.md](references/TESTOMAT_MARKDOWN_EXAMPLE.md)

package/skills/testomatio/test-management/improve-test-cases/references/TESTOMAT_MARKDOWN_EXAMPLE.md

@@ -1,66 +0,0 @@
-<!-- suite
-id: @S0a913xxx
-emoji: 🔐
-tags: smoke, regression
--->
-# Home Page Validation
-
-Verify that a guest user can view all critical UI elements on the Home page.
-
-## PREREQUISITES & SETUP
-1. Browser Requirements:
-   - Latest version of Chrome, Firefox, or Safari
-
-2. Test Environment:
-   - Application URL: "http://site.com"
-   - Screen resolution: 1920x1080 (recommended)
-   - Browser zoom: 100%
-
-3. Test Data:
-   - No specific test data required
-   - Guest user access (no authentication needed)
-
-4. Pre-test Setup:
-   - Clear browser cache and cookies
-   - Close all unnecessary browser tabs
-   - Ensure browser window is maximized
-
-<!-- test
-id: @Ts37c7xxx
-priority: normal
-tags: smoke
-labels: Manual
--->
-# Verify browser tab title
-
-## Description:
-Navigate to application base URL. Verify that the browser tab displays the correct title.
-
-## Preconditions:
-1. Navigate to application base URL: "http://site.com"
-
-## Steps:
-* Observe the browser tab title
-  _Expected_: Title contains "UI Test Automation Playground"
-
-<!-- test
-id: @T693f9xxx
-priority: normal
-tags: smoke
-labels: Manual
--->
-# Verify footer copyright text & links visibility
-
-## Description:
-Navigate to application base URL. Verify that the footer has correct copyright text and active links.
-
-## Preconditions:
-1. Navigate to application base URL: "http://site.com"
-
-## Steps:
-* Scroll to footer section
-  _Expected_: Footer is visible
-* Verify copyright text
-  _Expected_: Copyright text is correct (e.g., "© 2024 Company Name")
-* Verify footer links are active
-  _Expected_: All links are clickable and navigate to correct pages