@zohodesk/testinglibrary 0.0.41-n20-experimental → 0.0.42-n20-experimental

package/.github/styleGuides/Steps_README.md

@@ -0,0 +1,653 @@
+# Step Definitions Style Guide
+
+## Table of Contents
+
+1. [Imports & BDD Setup](#1-imports--bdd-setup)
+2. [Step Definition Syntax](#2-step-definition-syntax)
+3. [Context Destructuring](#3-context-destructuring)
+4. [Assertions](#4-assertions)
+5. [Test Data Management](#5-test-data-management)
+6. [CacheLayer & Data Sharing](#6-cachelayer--data-sharing)
+7. [Internationalization (i18N)](#7-internationalization-i18n)
+8. [Multi-Actor & Hooks](#8-multi-actor--hooks)
+9. [Helper Functions & Utilities](#9-helper-functions--utilities)
+10. [Barrel Exports (index.js)](#10-barrel-exports-indexjs)
+11. [Anti-Patterns to Avoid](#11-anti-patterns-to-avoid)
+12. [Checklist for New Step Definitions](#12-checklist-for-new-step-definitions)
+
+---
+
+### Naming Conventions
+
+| Artifact | Convention | Examples |
+|----------|-----------|----------|
+| **Module folders** | PascalCase | `Ticket/`, `CustomModule/`, `UserManagement/` |
+| **Spec files** | PascalCase | `SetupNavigation.spec.js`, `ContractCRUD.spec.js` |
+| **Feature files** | PascalCase, matching spec | `SupervisorCRUD.feature` |
+| **Assertion files** | PascalCase + `Assertions` suffix | `SetupAssertions.js`, `BusinessHoursAssertion.js` |
+| **Selector files** | PascalCase + `Selectors` suffix | `LayoutruleSelectors.js`, `DashboardSelectors.js` |
+| **Utility files** | PascalCase + `Utils` suffix | `TicketUtils.js`, `BusinessHourHelper.js` |
+| **Index files** | Lowercase | `index.js` |
+
+
+### Logic Placement Rules
+
+When deciding where to place code, strictly follow these data flow rules:
+- **If it is a locator string** → `dom-selectors/` (pure constants and builder helpers).
+- **If it clicks, fills, or reads UI** → `page-object-model/` (factory functions using selectors).
+- **If it wires a Gherkin step to a POM call** → `steps/` (thin Given/When/Then wiring).
+- **If it validates an outcome** → `assertions/` (if reused across 2+ spec files) or inline in the step itself.
+
+---
+
+## 1. Imports & BDD Setup
+
+### Standard Import Block
+
+Every spec.js file **must** begin with the BDD framework import and destructuring:
+
+```javascript
+import { createBdd } from '@zohodesk/testinglibrary';
+
+const { Given, When, Then } = createBdd();
+```
+
+- Import `And` only when needed: `const { Given, When, Then, And } = createBdd();`
+
+### Import Order (Recommended)
+
+Follow this import grouping, separated by blank lines:
+
+```javascript
+// 1. Framework imports
+import { createBdd, expect } from '@zohodesk/testinglibrary';
+
+// 2. Cross-module POM / shared imports
+import { FormActions } from '../../CommonActions';
+import { getModuleObj } from '../../Ticket/utils/ticketUtils';
+
+// 3. Module-local POM imports (via barrel export)
+import { ContractsDetailView, ContractFormPOM, ContractListPOM } from '../index';
+
+// 4. Assertions
+import Assertions from '../../_assertions/Assertions';
+import ContractAssertions from '../assertions/ContractAssertions';
+
+// 5. Constants (i18N keys, test data) — NOT selectors (selectors belong in POM only)
+import { I18N_KEYS } from '../constants/contractConstants';
+
+// 6. BDD destructuring (always last before step definitions)
+const { Given, When, Then } = createBdd();
+```
+
+---
+
+## 2. Step Definition Syntax
+
+### Given / When / Then Separation
+
+Maintain strict semantic separation:
+
+| Keyword | Purpose | Example |
+|---------|---------|---------|
+| **Given** | Set up preconditions & navigation | `Given('user is in setup home page', ...)` |
+| **When** | Perform user actions | `When('the user clicks {string} button', ...)` |
+| **Then** | Assert expected outcomes | `Then('the page should display {string}', ...)` |
+| **And** | Continue the preceding keyword | Chain additional Given or When actions or Then assertions |
+
+### Step Name Guidelines
+
+- Use `{string}` placeholders for dynamic values.
+- Keep steps **reusable** — avoid module-specific hardcoding in the step name.
+
+```javascript
+// ✅ Good — reusable and descriptive
+When('the user update the {string} field value to {string}', async ({ page }, field, value) => { ... });
+
+// ❌ Bad — too specific, not reusable
+When('update ticket subject', async ({ page }) => { ... });
+```
+
+### Parameter Patterns
+
+**Single string parameter:**
+```javascript
+When('the user access the {string} contact', async ({ page, i18N }, contact) => {
+    const ticketDv = await ticketDetailViewPOM({ page, i18N });
+    await ticketDv.goToContact(contact);
+});
+```
+
+**Multiple string parameters:**
+```javascript
+Then('the {string} {string} should be updated as {string}',
+    async ({ page, i18N }, moduleName, recordName, statusName) => {
+    const listViewPom = ListView({ page, i18N });
+    const statusElem = await listViewPom.getStatusElem(recordName, statusName, moduleName);
+    await Assertions.isElementVisible(statusElem);
+});
+```
+
+**DataTable parameter:**
+```javascript
+When('the user create a contract with below details',
+    async ({ page, i18N, getMetaInfo, cacheLayer }, dataTable) => {
+    const data = dataTable.hashes();          // Array of row objects
+    const form = await FormActions({ page, i18N, getMetaInfo, cacheLayer });
+    await form.fillForm(data[0]);
+});
+```
+
+**String + DataTable combined:**
+```javascript
+When('the user create a contract for {string} department with below details',
+    async ({ page, i18N, getMetaInfo, cacheLayer }, departmentName, dataTable) => {
+    const data = dataTable.hashes();
+    // ...
+});
+```
+
+### No Branching Logic in Step Definitions
+
+**A step definition must do exactly one thing — no `if/else`, `switch`, or ternary expressions** inside a step body. If conditional logic is needed, it belongs in the POM method; steps remain thin orchestrators.
+
+```javascript
+// ❌ Bad — branching inside a step
+When('the user saves the {string} form', async ({ page }, formType) => {
+    if (formType === 'ticket') {
+        await page.getByTestId('ticketSaveBtn').click();
+    } else {
+        await page.getByTestId('contactSaveBtn').click();
+    }
+});
+
+// ✅ Good — POM handles conditional logic internally
+When('the user saves the {string} form', async ({ page, i18N }, formType) => {
+    const form = FormPOM({ page, i18N });
+    await form.save(formType);
+});
+```
+
+---
+
+## 3. Context Destructuring
+
+### Available Context Objects
+
+Every step receives a context object as its first argument. Destructure **only what you need**:
+
+```javascript
+// Full set of available context properties:
+async ({ page, i18N, getMetaInfo, cacheLayer, context, executionContext, actorContext }, ...params) => {}
+```
+
+| Property | Type | Purpose |
+|----------|------|---------|
+| `page` | Playwright Page | Primary browser page interaction |
+| `i18N` | Function (async) | Translate i18N keys to localized strings |
+| `getMetaInfo` | Function (async) | Get current department, org info, actor info |
+| `cacheLayer` | Object | Share data between steps within a scenario |
+| `context` | Playwright BrowserContext | Multi-tab or multi-context operations |
+| `executionContext` | Object | Test execution info (edition, profile, actorInfo) |
+| `actorContext` | Object | Multi-actor support (switching user profiles) |
+
+### Usage Examples for Less Common Context Properties
+
+```javascript
+// executionContext — check the current edition
+When('the user checks edition-specific feature', async ({ page, executionContext }) => {
+    const { edition } = executionContext;
+    const featurePom = FeaturePOM({ page });
+    await featurePom.openEditionFeature(edition);
+});
+
+// actorContext — get the current actor's name
+Then('the comment author should be the current user', async ({ page, actorContext }) => {
+    const { name } = actorContext;
+    const authorElem = page.getByText(name);
+    await Assertions.isElementVisible(authorElem);
+});
+```
+
+### Destructure Only What You Need
+
+```javascript
+// ✅ Good — only destructure used properties
+When('user clicks save', async ({ page }) => { ... });
+
+When('user creates contract', async ({ page, i18N, getMetaInfo, cacheLayer }, dataTable) => { ... });
+
+// ❌ Bad — destructuring unused properties
+When('user clicks save', async ({ page, i18N, getMetaInfo, cacheLayer, context, executionContext }) => { ... });
+```
+
+---
+
+## 4. Assertions
+
+> Assertions must never be placed inside POM files. For the full decision guide on **when to use `assertions/` vs inline in the step file**, see [POM_README.md Rule 5](./POM_README.md#rule-5-keep-assertions-outside-pom).
+
+Quick rule: keep assertions inline in the step unless the same locator-read + assertion combination appears in **2+ different spec files** — then extract to `assertions/`.
+
+### Use the Centralized `Assertions` Library
+
+Always import from `_assertions/Assertions.js`. **Do not use raw `expect()` directly** unless there is no matching assertion method.
+
+### Then Steps Are Assertions Only
+
+**`Then` steps must never perform actions.** No clicks, form fills, navigation, or any mutations. Only assertions belong in a `Then` block.
+
+```javascript
+// ❌ Bad — action inside Then
+Then('the record is saved', async ({ page }) => {
+    await page.getByTestId('saveBtn').click();        // ← action in Then!
+    await Assertions.isElementVisible(page.getByText('Saved'));
+});
+
+// ✅ Good — Then only asserts
+Then('the record should be saved', async ({ page, i18N }) => {
+    const form = FormPOM({ page, i18N });
+    const confirmation = await form.getConfirmationElement();
+    await Assertions.isElementVisible(confirmation);
+});
+```
+
+```javascript
+import Assertions from '../../_assertions/Assertions';
+```
+
+### Available Assertion Methods
+
+```javascript
+// Visibility
+await Assertions.isElementVisible(element);
+await Assertions.isElementNotVisible(element);
+
+// Text / Value
+await Assertions.isElementHaveText(element, 'Expected text');
+await Assertions.isElementContainText(element, 'substring');
+await Assertions.isElementHaveValue(element, 'value');
+
+// Attributes
+await Assertions.isElementHaveAttribute(element, { attribute: 'aria-checked', value: 'true' });
+await Assertions.isElementHaveClass(element, 'active');
+
+// State
+await Assertions.isElementDisabled(element);
+await Assertions.isElementEnabled(element);
+await Assertions.isElementChecked(element);
+
+// Equality
+await Assertions.expectedToBe(actual, expected);
+
+// URL
+await Assertions.expectedURL(page, new RegExp(urlPattern));
+
+// Array Comparisons
+Assertions.verifySameElementsInOrder(actualArray, expectedArray);
+Assertions.verifySameElementsIgnoringOrder(actualArray, expectedArray);
+```
+
+### Playwright Auto-Waiting & Assertion Stability
+
+Playwright's built-in `expect()` assertions have **built-in auto-waiting** — they retry until the condition is met or a timeout expires. This makes them inherently more stable than plain JavaScript comparison methods.
+
+**Avoid plain JavaScript assertion methods for UI validations:**
+
+```javascript
+// ❌ Bad — toEqual() is a plain JS comparison with no auto-wait or retry
+const text = await element.textContent();
+expect(text).toEqual('Open');  // Flaky if the element updates asynchronously
+
+// ✅ Good — Playwright auto-waiting wrapped in our central library
+await Assertions.isElementVisible(element);
+await Assertions.isElementHaveText(element, 'Open');
+// Use native expect ONLY if a wrapper like toHaveCount doesn't exist yet
+await expect(element).toHaveCount(3);
+```
+
+### When to Use Direct `expect()`
+
+Only when the centralized `Assertions` library doesn't cover your case:
+
+```javascript
+// Acceptable — boolean comparison not covered by Assertions
+const isListed = await initialPage.isViewNameListed(viewName);
+expect(isListed).toBe(true);
+```
+
+---
+
+## 5. Test Data Management
+
+- Use **DataTable** parameters in feature files for structured test data.
+- Use `data-generator/` files for complex or reusable test data sets.
+- Never hardcode test values (record names, IDs, emails) directly in step definitions — pass them through feature file parameters or data generators.
+- Keep test data portable — do not depend on data that exists only in a specific environment.
+
+---
+
+## 6. CacheLayer & Data Sharing
+
+Use `cacheLayer` to share data between steps **within the same scenario**:
+
+```javascript
+// Step 1: Store data
+When('the user creates a ticket', async ({ page, cacheLayer }) => {
+    const ticketId = await createTicket(page);
+    await cacheLayer.set('createdTicketId', ticketId);
+});
+
+// Step 2: Retrieve data
+Then('the ticket should appear in detail view', async ({ page, cacheLayer }) => {
+    const ticketId = await cacheLayer.get('createdTicketId');
+    await page.goto(`/tickets/${ticketId}`);
+});
+```
+
+### Rules
+
+- Use **descriptive keys** for cached values.
+- Cache only **primitive values or simple objects**.
+- Pass `cacheLayer` to POMs when they need access to shared data.
+
+### No Global or Environment Variables for Test Data
+
+**Never store test-specific runtime data in `process.env`, module-level variables, or any global scope.** Use `cacheLayer` for scenario-scoped sharing.
+
+```javascript
+// ❌ Bad — module-level global (leaks between scenarios)
+let createdTicketId;
+When('the user creates a ticket', async ({ page }) => {
+    createdTicketId = await createTicket(page);
+});
+
+// ❌ Bad — environment variable mutation (persists globally)
+When('the user creates a ticket', async ({ page }) => {
+    process.env.TICKET_ID = await createTicket(page);
+});
+
+// ✅ Good — cacheLayer is isolated to the current scenario
+When('the user creates a ticket', async ({ page, cacheLayer }) => {
+    const ticketId = await createTicket(page);
+    await cacheLayer.set('ticketId', ticketId);
+});
+```
+
+---
+
+## 7. Internationalization (i18N)
+
+> Rule definition: all user-facing strings must use `i18N` — see [POM_README.md Rule 21](./POM_README.md#rule-21-use-i18n-for-all-user-facing-strings).
+
+This section covers `i18N` usage patterns specific to step definitions.
+
+### Usage in Steps
+
+`i18N` is an **async function** — always `await` it:
+
+```javascript
+When('user verifies the label', async ({ page, i18N }) => {
+    const labelText = await i18N('desk.tickets.status.open');
+    const element = page.getByText(labelText);
+    await Assertions.isElementVisible(element);
+});
+```
+
+### Usage via Constants
+
+```javascript
+// Define constants
+const I18N_CONSTANTS = {
+    ACTIVE_FILTER: 'desk.filter.active',
+    SAVE_BUTTON: 'desk.common.save'
+};
+
+// Use in steps
+const saveText = await i18N(I18N_CONSTANTS.SAVE_BUTTON);
+```
+
+### Rules
+
+- **Always use `i18N` for user-facing strings** — never hardcode English text.
+- Pass `i18N` to POMs that need to match labels or button text.
+- Group `i18N` keys in **constants files** for maintainability.
+
+---
+
+## 8. Multi-Actor & Hooks
+
+### Switching Between Actors
+
+The following step is **already built into the framework** — do **not** create a new step definition for it. When this step appears in a feature file, it is automatically resolved from the framework side:
+
+```gherkin
+Given access the "admin" profile page
+```
+
+> **No spec.js implementation needed.** This step is pre-registered in the shared test framework (`@zohodesk/testinglibrary`) and handles actor switching internally.
+
+### Rules
+
+- **Do not re-implement framework-provided steps** — if a step like `Given('access the {string} profile page')` already exists in the framework, reuse it as-is.
+
+---
+
+## 9. Helper Functions & Utilities
+
+### When to Extract a Helper### Routing "Helper" Logic
+
+Do not create arbitrary "helper" functions inside step definition files. When logic becomes repetitive or complex, extract it strictly according to the framework layers:
+
+* **UI Interaction Helpers (Waits, Clicks, Forms):** If multi-step UI logic or wait logic is reused across steps, extract it as a new action method inside the target **Page Object Model (POM)**.
+
+* **Validation Helpers:** If a complex, multi-line validation is reused across 2+ different `.spec.js` files, extract it to the module's `assertions/` folder.
+
+* **Pure Data Utilities:** Only create a standalone utility file (e.g., `utils/dateFormatter.js`) if the logic is **pure data manipulation** (e.g., math, string formatting, regex, generating random emails) and contains absolutely zero Playwright imports or DOM interactions.
+
+```javascript
+// ✅ Good — extracted to utils
+export async function switchView(page, getMetaInfo, moduleName, viewName) {
+    const { currentDepartment, actorInfo } = await getMetaInfo();
+    const { orgName } = actorInfo;
+    const sanitizedViewName = getSanitizedName(viewName);
+    const sanitizedModuleName = getSanitizedName(moduleName);
+    await page.goto(`${process.env.domain}/${orgName}/${sanitizedDeptName}/${sanitizedModuleName}/list/${sanitizedViewName}${process.env.devUrl}`);
+    const topbar = await page.getByTestId(COMMON_SELECTORS.TOP_BAND_HEADER);
+    await topbar.waitFor();
+}
+
+// Helper for text sanitization
+export const getSanitizedName = (name = '') => {
+    return name.replace(/\s/g, '-').replace(/_/g, '').toLowerCase();
+};
+```
+
+### Waiting Patterns
+
+```javascript
+// ✅ Preferred — wait for page load
+await page.waitForLoadState('load');
+await page.waitForLoadState('domcontentloaded');
+
+// ✅ Preferred — wait for a specific element (strongest validation)
+await element.waitFor();
+await element.waitFor({ state: 'hidden' });
+
+// ✅ Wait for specific API response
+await page.waitForResponse(
+    res => res.url().includes('tickets') && res.status() === 200
+);
+
+// ⚠️ Use with caution — networkidle (see warning below)
+await page.waitForLoadState('networkidle');
+
+// ❌ Never use fixed waits
+await page.waitForTimeout(1000);
+```
+
+### ⚠️ Avoid `networkidle` for Element Verification
+
+**When to use `networkidle`:**
+- It's **not** that `networkidle` should never be used — but it should **only** be applied where it is truly required (e.g., ensuring all resources are fully downloaded before taking a screenshot or exporting a PDF).
+
+- **Never** use it as a substitute for element-based validation.
+
+**What to use instead:**
+```javascript
+// ✅ Good — element-based validation (strongest and most reliable)
+await element.waitFor();
+await Assertions.isElementVisible(element);
+
+// ✅ Good — wait for page load events
+await page.waitForLoadState('load');
+await page.waitForLoadState('domcontentloaded');
+
+// ❌ Bad — using networkidle to verify element presence
+await page.waitForLoadState('networkidle');
+await Assertions.isElementVisible(element);  // flaky!
+```
+
+### DOM Readiness Validation Before Actions
+
+**Always confirm an element is present and stable before performing an action on it.** Never interact with an element immediately after navigation without waiting.
+
+```javascript
+// ❌ Bad — no DOM readiness check
+async clickStatusDropdown() {
+    await this.page.getByTestId('statusDropdown').click();   // may not exist yet
+},
+
+// ✅ Good — wait for element before acting
+async clickStatusDropdown() {
+    const dropdown = this.page.getByTestId('statusDropdown');
+    await dropdown.waitFor();      // confirms DOM is ready
+    await dropdown.click();
+},
+```
+
+### Rules
+
+- **Validate DOM readiness with `waitFor()`** before every action in POM methods — see [POM_README.md Rule 13](./POM_README.md#rule-13-validate-dom-readiness-before-any-action).
+
+---
+
+## 10. Barrel Exports (index.js)
+
+Each module must have a root `index.js` that exports all public POMs, assertions, and utilities:
+
+> **Note:** This is the **module root** barrel (`modules/<ModuleName>/index.js`). There is also a **POM-internal** barrel (`page-object-model/index.js`) that re-exports only POM factory functions — see [POM_README.md Rule 20](./POM_README.md#rule-20-use-barrel-exports-for-local-module-poms). The module root barrel consumes the POM barrel and adds assertions and utilities.
+
+```javascript
+// modules/Contract/index.js
+export { default as ContractsDetailView } from './page-object-model/ContractsDetailView';
+export { default as ContractFormPOM } from './page-object-model/ContractFormPOM';
+export { default as ContractListPOM } from './page-object-model/ContractListPOM';
+
+export { default as ContractAssertions } from './assertions/ContractAssertions';
+export { getContractData } from './utils/contractUtils';
+```
+
+### Rules
+
+- **One `index.js` per module** — re-export everything needed externally.
+- **Import from `../index`** in step definitions, not from deep paths.
+- Keep internal files (selectors, helpers) out of barrel exports unless used cross-module.
+
+---
+
+## 11. Anti-Patterns to Avoid
+
+
+### ❌ Business Logic in Step Definitions
+
+```javascript
+// ❌ Bad — loop logic belongs in POM
+Then('all rules should be listed', async ({ page }, dataTable) => {
+    const rules = dataTable.hashes();
+    for (const { ruleName } of rules) {
+        const elem = page.getByText(ruleName);
+        await Assertions.isElementVisible(elem);
+    }
+});
+
+// ✅ Good — delegate to POM
+Then('all rules should be listed', async ({ page }, dataTable) => {
+    const rules = dataTable.hashes();
+    const ruleList = RuleListPOM({ page });
+    await ruleList.verifyRulesListed(rules);
+});
+```
+
+### ❌ Unused Context Destructuring
+
+```javascript
+// ❌ Bad
+When('step', async ({ page, i18N, getMetaInfo, cacheLayer, context, executionContext }) => {
+    await page.click('#btn');
+});
+
+// ✅ Good
+When('step', async ({ page }) => {
+    const form = FormPOM({ page });
+    await form.clickBtn();
+});
+```
+
+### ❌ Missing Barrel Exports
+
+```javascript
+// ❌ Bad — deep path imports
+import ContractFormPOM from '../page-object-model/ContractFormPOM';
+import ContractListPOM from '../page-object-model/ContractListPOM';
+
+// ✅ Good — via index.js
+import { ContractFormPOM, ContractListPOM } from '../index';
+```
+
+### ❌ Hardcoded IDs or Locators in Step Definitions
+
+All locators must live in the selector file and be accessed through POM methods — never inline raw `data-testid` strings or CSS selectors in a step:
+
+```javascript
+// ❌ Bad — raw locator inline in step
+When('the user opens the ticket', async ({ page }) => {
+    await page.locator('[data-testid="ticketDetail-12345"]').click();
+});
+
+// ✅ Good — locators live in the selectors file, accessed via POM
+When('the user opens the ticket', async ({ page, i18N }) => {
+    const list = TicketListPOM({ page, i18N });
+    await list.openFirstTicket();
+});
+```
+---
+
+## 12. Checklist for New Step Definitions
+
+Use this checklist when creating a new spec.js file:
+
+- [ ] **File placed** in `modules/<ModuleName>/steps/` directory
+- [ ] **File named** in PascalCase with `.spec.js` extension
+- [ ] **Imports** follow the standard order (framework → cross-module → local → assertions → selectors → BDD destructuring)
+- [ ] **`createBdd()`** called and destructured for only needed keywords
+- [ ] If the step already exists → reuse it instead of creating a new one. If the step does not   exist → create new steps.
+- [ ] **Given/When/Then** semantically separated (setup → action → assertion)
+- [ ] **Step names** are descriptive Gherkin English with `{string}` parameters
+- [ ] **Context destructured** with only used properties
+- [ ] **All DOM interactions** delegated to POMs — no raw selectors in steps
+- [ ] **Assertions** use the centralized `Assertions` library
+- [ ] **Test data** managed via utility functions or DataTable, not hardcoded
+- [ ] **i18N used** for all user-facing strings
+- [ ] **No hardcoded timeouts** — use explicit wait conditions
+- [ ] **Corresponding feature file** exists with matching name and proper tags
+- [ ] **Module `index.js`** updated if new POMs or exports are added
+- [ ] **Helper functions** extracted for reused logic, placed in `utils/`
+- [ ] **No branching logic** (`if/else`, `switch`, ternary) inside any step definition — move to POM
+- [ ] **`Then` steps contain only assertions** — no clicks, fills, or navigation
+- [ ] **Scenarios are independent** — can run in any order without relying on shared state
+- [ ] **No global variables or `process.env` mutations** for test data — use `cacheLayer`
+- [ ] **No hardcoded locators or IDs** in step definitions — all DOM access via POM methods
+- [ ] **DOM readiness verified** with `waitFor()` before performing actions in POM methods
+
+---

package/.vscode/mcp.json

@@ -6,4 +6,4 @@
       "args": ["playwright", "run-test-mcp-server"]
     }
   }
-}
+}

package/build/core/playwright/constants/reporterConstants.js

@@ -11,6 +11,5 @@ const stage = (0, _ConfigurationHelper.getRunStage)();
 class ReporterConstants {
   static DEFAULT_REPORTER_PATH = `${_configConstants.default.TEST_SLICE_FOLDER}/${stage}/test-results/playwright-test-results.json`;
   static LAST_RUN_REPORTER_PATH = `${_configConstants.default.TEST_SLICE_FOLDER}/${stage}/test-results/.last-run.json`;
-  static DEFAULT_UNIT_TEST_REPORTER_PATH = `${_configConstants.default.TEST_SLICE_FOLDER}/unit-test/unit_reports/report.html`;
 }
 exports.default = ReporterConstants;