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-automation/automate-manual-test-cases/SKILL.md DELETED Viewed

@@ -1,242 +0,0 @@
----
-name: automate-manual-test-cases
-description: This skill converts manual test cases into production-ready automated test scripts. It analyzes the existing automation framework, interprets manual test steps, and generates maintainable tests following automation best practices. Use this skill whenever the user wants to automate manual test cases, expand test coverage, or create end-to-end automated flows from existing test documentation.
-license: MIT
-metadata:
-  author: Testomat.io
-  version: 1.0.0
----
-# Automate Manual Test Cases
-Generate production-ready automated test scripts from manual test cases, reusing the project's existing framework, patterns, and components.
-## Checklist
-Complete all steps in order:
-1. [ ] Analyze project architecture => detect framework (1.1), analyze conventions (1.2), find reusable components (1.3).
-2. [ ] Understand manual test => normalize input (2.1), handle ambiguous steps (2.2), detect inconsistencies (2.3).
-3. [ ] Write test code => implement using existing POM/patterns (3.1-3.2), add assertions (3.3), output code (3.4).
-4. [ ] Verify & heal => execute test (4.1), heal if fails: locators → timing → assertions → flow (4.2), **max 3 attempts**.
-5. [ ] Finalization => save test (5.1), manage test data & fixtures (5.2), run related tests and output summary (5.3).
-### Progress
-* STEP: 1/5 (Analyze Project Architecture)
-* Previous: (none)
-* Next ➡️ Step 2: Understand Manual Test.
-Update this block after completing each step (see CLAUDE.md).
-## Step 1: Analyze Project Architecture
-### 1.1 Detect Automation Framework
-- If the user specifies a framework (e.g., "use CodeceptJS") => trust it.
-- Otherwise inspect the project:
-  - `package.json` dependencies and scripts.
-  - Config files (`playwright.config.js`, `codecept.conf.js`, `cypress.json`, etc.).
-- If detection fails, ask with numbered options:
-  ```
-  ❓ Which framework should I use?
-  1. Playwright
-  2. CodeceptJS
-  3. Cypress
-  4. Other (specify)
-  ```
-After detection, apply the matching reference:
-- [CodeceptJS Best Practices](./references/CODECEPTJS_BEST_PRACTICES.md)
-- [Playwright Best Practices](./references/PLAYWRIGHT_BEST_PRACTICES.md)
-### 1.2 Analyze Project Conventions
-- Test structure and naming: folders (`tests/`, `e2e/`) and file patterns (`*.spec.js`, etc.).
-- Execution: `package.json` scripts and test commands.
-- Configuration: base URLs, env variables, global setup.
-- Assertion style: libraries and patterns used in existing tests.
-### 1.3 Identify Reusable Components
-Scan for:
-- Page Objects: existing locators and methods (`src/pages`, `pages/`, `page-objects/`, etc.).
-- Fixtures/hooks: setup and teardown patterns.
-- Test data: constants, CSV, JSON (`test-data`, `src/testData`, etc.).
-- Utils/helpers (`utils/`, `helpers/`, etc.).
-Exclude from analysis:
-- Dependency folders (`node_modules/`).
-- Build artifacts (`dist/`, `build/`, `out/`).
-- Hidden/system folders (`.git/`, `.cache/`).
-- Deprecated code: `deprecated/`, `legacy/`, `old/`, `backup/`, `__backup__/`, `archive/`, `temp/`, files marked `outdated`, older versioned folders (`v1/`, `v2/`) when newer versions exist.
-- Do not auto-exclude folders with unclear purpose.
-- **User-specified exclusions always override auto-detected ones.**
-## Step 2: Understand Manual Test
-Input may be plain text, markdown steps, or comment blocks in source files (`//`, `/* */`).
-### 2.1 Normalize Input Structure
-Convert input into:
-- `summary` (or scenario title).
-- `preconditions` (optional).
-- `steps` (required) — ordered actions with expected results.
-For comment-based inputs:
-- Treat comment markers (`//`, `*`, `-`) as structural hints.
-- Convert bullet points into ordered steps.
-- Bind `_Expected:_` or `Expected Results` blocks to the preceding step.
-- Merge multiline expected results into a single logical expectation.
-Example:
-```md
-* Navigate to page
-  _Expected:_ Page opens
-* Click once on the ${Custom statuses} block
-  _Expected_: List includes "manual" option.
-```
-**Do not delete or rewrite original manual test comments.**
-- Keep them as-is in the file.
-- Generate automation code below or alongside them.
-- Separate with a marker: `// === AUTO-GENERATED TEST (based on steps above) ===`
-### 2.2 Handle Ambiguous Steps
-Classify each step:
-- Clear => proceed.
-- Partially clear => make a reasonable assumption, mark it with ⚠️ in output (e.g., "⚠️ Assuming 'Submit' button triggers form submission"), continue.
-- Unclear and blocking => ask the user, with numbered options when there are alternatives:
-  ```
-  ❓ Do you want to:
-  1. Use existing LoginPage
-  2. Create new LoginPage
-  3. Skip login step
-  ```
-Use context from previous steps and common UI patterns (click, input, navigation).
-**Do not block the whole flow on one unclear step — continue with the rest.**
-### 2.3 Detect Inconsistencies
-If step actions, expected results, and known UI patterns disagree:
-- Proceed with best-effort interpretation.
-- Flag with ⚠️ in output.
-## Step 3: Write Test Code
-### 3.1 Choose Implementation Strategy
-- Reusable components exist (Page Objects, helpers, fixtures) => reuse them; follow project patterns and naming.
-- Partial structure exists => extend existing components; keep consistency with current design.
-- No structure => simple readable locators, minimal implementation, no unnecessary abstractions.
-Priorities: consistency with the project, then readability, then maintainability.
-**Do not ignore existing Page Objects or duplicate selectors/logic.**
-### 3.2 Follow Framework Patterns
-- One test, one flow — each test validates a single scenario.
-- Separation of concerns: tests => assertions and flow control; Page Objects => UI interactions; utils => reusable logic.
-- Extend, don't modify — add to existing components without changing stable code.
-- Use fixtures for setup, authentication, and shared state.
-See [POM Best Practices](./references/POM_BEST_PRACTICES.md).
-### 3.3 Generate Assertions
-- Base assertions on expected results from manual steps.
-- Validate UI state (visibility, text, attributes), data correctness, navigation outcomes.
-- Avoid weak assertions (only checking page load) and over-asserting irrelevant details.
-### 3.4 Output Test Code
-- Generate complete, runnable code that integrates with the existing framework.
-- Follow project formatting and style conventions.
-- Place code in the appropriate test file or suggest a location.
-## Step 4: Verify & Heal
-### 4.1 Execute Test
-**Run only the generated test, never the full suite:**
-- Playwright: `npx playwright test path/to/spec.ts`
-- CodeceptJS: `npx codeceptjs run path/to/test.js`
-If it passes => go to Step 5. If it fails => heal (4.2).
-### 4.2 Heal Failed Tests
-Fix one issue at a time, in priority order:
-1. Locators — prefer stable selectors (`data-testid`, `aria-label`), avoid deeply nested XPath.
-2. Timing — use framework-native waits, avoid hard sleeps.
-3. Assertions — match actual app behavior, not assumptions.
-4. Flow — verify navigation, preconditions, missing steps.
-Process: identify a single failure => apply one fix => re-run => repeat.
-Keep the last working version to roll back to if stuck.
-**Max 3 healing attempts. If still failing, stop and report the issues.**
-When the root cause is unclear, use the debug-fix-failed-flaky-autotests skill for structured step-by-step diagnosis.
-If MCP/debug tools are available:
-- Inspect DOM (`document.querySelector(...).outerHTML`).
-- Use step-by-step execution.
-- Capture logs, screenshots, or traces.
-### 4.3 Stability Criteria
-A test is stable when it:
-- Passes 1-2 consecutive runs.
-- Has no hard waits.
-- Uses resilient locators.
-## Step 5: Finalization
-### 5.1 Save Final Test Code
-- Save the working test to the appropriate project location.
-- Follow naming conventions and stay consistent with existing tests.
-### 5.2 Test Data & Fixtures
-- Use centralized test data if the project has it (JSON/CSV/constants).
-- Reuse authentication/setup fixtures; don't duplicate setup inside tests.
-See [Test Data Management](./references/TEST_DATA_MANAGEMENT.md).
-### 5.3 Final Run & Summary
-- Execute 1-2 related tests to confirm integration (related tests only, not the full suite).
-- Exit condition: test passes 2 consecutive runs.
-- Show a spec-to-code mapping:
-  | Manual Step | Automation Action |
-  |-------------|-------------------|
-  | Navigate to Settings | `basePage.clickOnNavigationMenuButton("Settings")` |
-- Output the final summary using [Final Summary Template](./references/FINAL_SUMMARY_TEMPLATE.md).
-## Example: Comment-Based Request
-```
-Use automate-manual-test-cases skill for CodeceptJS framework to write automation
-script "tests/plan-for-guest.test.ts" based on manual steps below in this file as
-comments (leaving comments in the file for further analysis). Set a specific "smoke"
-tag for this test.
-Use as reference for extra proper examples:
-* `tests/payment-methods.test.ts` - Canonical test file with team approved format.
-* `src/pages/paymentMethods.page.ts` - Good described payment page object.
-Avoid mistakes from legacy code examples:
-* `src/pages/paymentOutdated.page.ts` - Outdated example with old patterns.
-Finally, verify that the generated test is passed on - `BASE_URL = 'https://test.com/'`
-and provide final review for user.
-```

package/skills/testomatio/test-automation/automate-manual-test-cases/references/CODECEPTJS_BEST_PRACTICES.md DELETED Viewed

@@ -1,182 +0,0 @@
-# CodeceptJS Best Practices
-High-level CodeceptJS-specific recommendations. They complement general testing and POM best practices.
-Prefer adapting to the existing project over enforcing new patterns.
-## Architecture
-Think in layers of responsibility, not folders. Each layer has one job — do not mix locators, business logic, and assertions:
-- Pages: dumb locator containers with simple UI interactions only. No business logic.
-- Actors (I) / Custom Steps: own business logic; orchestrate Page actions into domain workflows, multi-step interactions, conditional logic.
-- Helpers / Utilities: low-level technical operations — browser automation wrappers (Playwright, WebDriver, Puppeteer), API calls, DB access, file operations, custom locators.
-- Test Data / Constants: shared configuration, constants, enums, mock data, fixtures.
-- Plugins / Extensions: optional enhancements — auto-login, soft assertions, reporting.
-- Tests / Specs: independent, readable, scenario-focused.
-Choose the simplest approach that matches the project:
-- If project uses Page Objects => use them.
-- Else => interact directly in tests.
-### Register New Page Objects
-After creating a new page object file, add it to:
-1. `codecept.conf.ts` — `include` section
-2. `steps.d.ts` — type declarations
-## Naming Rules
-No abbreviations — always write full words:
-| Wrong | Correct |
-|-------|---------|
-| `Nav` | `Navigation` |
-| `Btn` | `Button` |
-| `Pg`  | `Page` |
-Locator names must include the element type as a suffix:
-| Wrong (no type) | Correct (with type) |
-|-----------------|---------------------|
-| `compareOverview` | `compareOverviewSection` |
-| `finishRun` | `finishRunButton` |
-| `runGroupTitle` | `runGroupTitleHeader` |
-## Locator Strategy
-Priority:
-1. Semantic text / element roles (`I.seeElement()`, `{ name: 'field' }`).
-2. CSS ID selectors.
-3. `data-testid` (when semantic locators aren't possible).
-4. Custom locators (last resort).
-```javascript
-// Good locators
-I.click('Submit')
-I.fillField('Email', 'user@test.com')
-I.click({ testId: 'submit-form-btn' })
-I.click('.btn-primary.submit-form') // only if necessary
-```
-### Reusing Locators
-- Before creating a new locator, search `src/pages/`, `pages/`, `components/`.
-- If a locator for the same element already exists — reuse it.
-- Avoid duplicates (e.g. `reportButton` vs `combinedReportButton`) — they create confusion and maintenance issues.
-### Tab Active State Verification
-After clicking a tab, verify it is active. Different implementations use different indicators:
-```typescript
-private generateActiveTabLocator(tabName: string) {
-  return locate('[role="tab"][aria-selected="true"]').withText(tabName);
-}
-checkThatTabIsActive(tabName: string) {
-  const activeTab = this.generateActiveTabLocator(tabName);
-  I.waitForElement(activeTab, timeouts.THREE);
-  I.seeElement(activeTab);
-}
-```
-## Custom Steps (Actor Methods)
-- Multi-step logic belongs in Actor methods.
-- Use for login, conditional flows, API+UI flows, or explicit waits.
-```javascript
-module.exports = function() {
-  return actor({
-    async loginAs(email, password) {
-      I.amOnPage('/login')
-      I.fillField('Email', email)
-      I.fillField('Password', password)
-      I.click('Sign In')
-      I.waitForUrl('**/dashboard')
-    },
-    async ensureLoggedIn(user) {
-      const loggedIn = await I.grabNumberOfVisibleElements('.logout-button') > 0
-      if (!loggedIn) await this.loginAs(user.email, user.password)
-    }
-  })
-}
-```
-## Fixtures & Hooks
-- Use `Before` hook for setup and authentication.
-- Use `After` hook for cleanup (API cleanup only, no UI).
-- Reuse existing fixtures when present in the project.
-```typescript
-Before(async ({ app }) => {
-  const login = await app.login(token);
-  app.setToken(`Bearer ${login.data.jwt}`);
-  loginAs("mainUser");
-});
-After(async ({ app }) => {
-  await app.cleanup();
-});
-```
-### Test Data Usage
-Prefer shared constants, enums, or test data over hardcoded values:
-```typescript
-import { timeouts } from "../testData/timeout";
-I.waitForElement(locator, timeouts.THREE); // 3s
-```
-### API in Preconditions, UI for Test Steps
-- Before hook: use API to create test data (users, projects, runs, etc.).
-- Scenario body: use UI interactions — that is what the test is verifying.
-- Exception: simple navigation to a starting URL in Before is acceptable.
-### Formatting Rules
-- One blank line between every action in Scenario body.
-- No step comments inside Scenario body — method names must be self-documenting.
-- No magic strings in test body — extract to `const` at top of file.
-- No long `projectData.x.y.z.w` chains in test body — extract to named `const`.
-## Test Tags & Filtering
-- Tagging and filtering are project-specific.
-- If the project already uses tags (e.g., @Smoke, @Regression, @P0), follow existing conventions.
-- Do not introduce new tagging systems unless explicitly required.
-## Debugging & Reporting
-- Use `--debug` / `--verbose`.
-- Save screenshots: `I.saveScreenshot('name.png')`.
-- Playwright traces can be enabled in helper config.
-- Custom helpers: `DebugHelper` for logs, screenshots, pause.
-## Anti-Patterns (Avoid)
-- Never hardcode test data — use data files or environment variables.
-- Never share state between tests — each test sets up its own state.
-- Never commit secrets or credentials — use environment variables.
-- Never ignore flaky tests — fix immediately with proper waits.
-- Never skip test cleanup — use After hooks.
-- Prefer semantic locators (`{ name: 'button' }`) over CSS-only (`.btn-primary`).
-Code smells from legacy code (do not repeat):
-- Hardcoded waits (like `I.wait(n)`).
-- Inline cleanup inside test scenarios (`// cleanup`).
-- Locators directly in test files instead of page objects.
-- Hardcoded IDs and config values in tests.
-## Checklist
-- [ ] Keep tests independent — each test sets up its own state
-- [ ] Use test data constants instead of hardcoded values
-- [ ] Follow naming rules (full words, element type suffix)
-- [ ] Reuse existing locators before creating new ones
-- [ ] Add assertions based on expected results from manual steps

package/skills/testomatio/test-automation/automate-manual-test-cases/references/FINAL_SUMMARY_TEMPLATE.md DELETED Viewed

@@ -1,22 +0,0 @@
-# Final Summary Template
-Use this template after completing the conversion process:
-```
-**Summary:**
-- Framework: [Playwright/CodeceptJS/Cypress]
-- Tests generated: [N]
-- Passed: [N]
-- Needs review: [N]
-**Generated Files:**
-- [path/to/test1.spec.ts] ✅
-- [path/to/test2.spec.ts] ⚠️ ([issue])
-- [path/to/test3.spec.ts] ✅
-**Key Issues:**
-[Short description of main problems, if any]
-**Next steps:**
-...
-```

package/skills/testomatio/test-automation/automate-manual-test-cases/references/PLAYWRIGHT_BEST_PRACTICES.md DELETED Viewed

@@ -1,90 +0,0 @@
-# Playwright Best Practices
-High-level Playwright-specific recommendations. They complement general testing and POM best practices.
-Prefer adapting to the existing project over enforcing new patterns.
-## Architecture & Project Structure
-- Do not assume a fixed architecture (e.g., Pages, Modules, Fixtures).
-- Detect and follow the existing project structure.
-- Common patterns may include:
-  - Pages: dumb locator containers with simple element interactions only.
-  - Modules: own all business logic, orchestrate Page actions into domain workflows.
-  - Fixtures: dependency injection — tests never instantiate Pages or Modules directly.
-  - `test.step()`: use for reporting, trace analysis, and debugging.
-Choose the simplest approach that matches the project:
-- If project uses Page Objects => use them.
-- Else => interact directly in tests.
-## Locator Strategy
-- Prefer user-facing and semantic locators.
-- Use built-in Playwright locator strategies when possible.
-- Prefer stability over brevity.
-- Avoid selectors tied to layout or styling.
-Priority:
-1. Role-based selectors (buttons, links, alerts).
-2. Labels (form inputs).
-3. Visible text.
-4. Test-specific attributes (data-testid).
-5. CSS selectors.
-Stay consistent within the project:
-- If the project relies on semantic locators => follow that pattern.
-- If it uses test IDs => prefer `data-testid` as the primary selector.
-```typescript
-// Preferred (semantic)
-await page.getByRole('button', { name: 'Submit' }).click()
-await page.getByLabel('Email').fill('user@test.com')
-// Fallback (only if necessary)
-await page.locator('.btn-primary.submit-form').click()
-```
-## Fixtures
-- Playwright provides built-in fixtures (e.g., `page`, `context`, `request`).
-- Reuse existing custom fixtures for setup, authentication, or shared state.
-- If no fixture structure exists, simple tests can interact directly without introducing abstraction.
-- Introduce new fixtures only when they clearly improve reuse, readability, or setup consistency.
-## API Testing
-Playwright supports both API and UI interactions via `request`.
-- Prefer API for: test setup, teardown, data preparation.
-- Use UI for: behavior validation, end-user flows.
-- Pattern: setup via API, verify via UI.
-## Test Tags & Filtering
-- Tagging and filtering are project-specific.
-- If the project already uses tags (e.g., @Smoke, @Regression, @P0), follow existing conventions.
-- Do not introduce new tagging systems unless explicitly required.
-## Debugging & Reporting
-- Use built-in Playwright debugging tools or Playwright MCP when needed: traces, screenshots, logs.
-- Add extra steps or logs only if they improve clarity.
-- Avoid excessive logging or noise in tests.
-## Anti-Patterns (Avoid)
-- Never embed test data directly in test logic — prefer centralized test data (JSON, factories, or generators).
-- Never share state between tests — each test is isolated.
-- Never ignore flaky tests — fix immediately with proper waits.
-- Never use arbitrary `sleep()` — use explicit waits instead.
-- Never commit secrets or credentials — use environment variables.
-- Never over-abstract simple test flows.
-## Checklist
-- [ ] Use `test.step()` for reporting and trace analysis
-- [ ] Use API for setup/teardown over UI when possible
-- [ ] Keep tests independent — each test sets up its own state
-- [ ] Use test data instead of hardcode
-- [ ] Run tests in parallel (when safe)
-- [ ] Implement soft assertions for non-critical checks

package/skills/testomatio/test-automation/automate-manual-test-cases/references/POM_BEST_PRACTICES.md DELETED Viewed

@@ -1,53 +0,0 @@
-# Page Object Model (POM) Best Practices
-## Core Principles
-### Single Responsibility
-- Each Page Object represents one page or a clearly defined UI component.
-- Each method performs a single, clear action.
-- Keep structure flat and simple.
-- Avoid unnecessary abstractions.
-- Introduce shared components only when reuse is clear.
-### Encapsulation
-- Hide implementation details such as selectors and waiting logic.
-- Expose only meaningful, high-level actions to tests.
-- Do not expose raw selectors outside the Page Object.
-### Reusability
-- Extract shared logic only when reuse is clear.
-- Extract shared functionality into parent classes.
-- Use composition over inheritance when appropriate.
-## Wait Strategies
-- Use condition-based waits (element visible, enabled, loaded).
-- Avoid fixed delays or hard waits.
-- Rely on framework auto-waiting where available.
-- Do not duplicate waiting logic unnecessarily.
-```typescript
-// Bad: hard wait
-await page.waitForTimeout(5000)
-```
-## Error Handling
-- Do not override or wrap framework errors for UI interactions.
-- Rely on built-in error handling for element actions.
-- Avoid adding manual visibility or existence checks before actions.
-- Add contextual error handling only for:
-  - API interactions
-  - Data processing
-  - Non-UI logic
-## Summary Checklist
-- [ ] One class per page/component.
-- [ ] Private/protected locators.
-- [ ] Explicit waits over hard waits.
-- [ ] Meaningful method names.
-- [ ] No assertions in Page Objects.
-- [ ] Reusable component structure.
-- [ ] Clear error messages.

package/skills/testomatio/test-automation/automate-manual-test-cases/references/TEST_DATA_MANAGEMENT.md DELETED Viewed

@@ -1,52 +0,0 @@
-# Test Data Management
-## Core Principles
-- Test data must support the test scenario, not define it.
-- Keep test data minimal, relevant, and easy to understand.
-- Ensure tests remain independent and do not rely on shared mutable data.
-- Prefer clarity over reusability when in conflict.
-## Data Placement Strategy
-When deciding where to store test data:
-1. If data is used only within a single test => Keep it simple or inline within that test.
-2. If data is reused across multiple tests => Extract it into a shared test-data.
-3. If data is large, structured, or tabular => Store it in external files (e.g., JSON, CSV).
-  - LOAD data from external file.
-  - ITERATE over dataset in tests.
-4. If data depends on environment (URLs, credentials, configs) => Use environment variables or configuration files.
-  - READ baseUrl from environment.
-  - USE baseUrl in test.
-**Priority:** Start local - Extract only when reuse is clear.
-## Data Structure Guidelines
-- Use clear, descriptive names for all data variables.
-- Keep data structures simple and predictable.
-- Avoid deeply nested or overly complex data unless required.
-- Group related data logically (e.g., user profiles, product sets).
-## Test Isolation Rules
-- Each test must be fully independent.
-- Tests must not share mutable data or state.
-- Avoid dependencies between tests.
-- Prefer framework-provided isolation over manual resource handling.
-## Reusability Guidelines
-- Reuse test data only when it reduces duplication and improves clarity.
-- Do not over-centralize data if it makes tests harder to read.
-- Keep frequently used data in shared modules.
-- Keep unique or scenario-specific data close to the test.
-## Anti-Patterns to Avoid
-- Hardcoding credentials or secrets in test files.
-- Using real user or production data.
-- Sharing state between tests.
-- Creating test data without cleanup.
-- Over-engineering data structures for simple scenarios.