updated readme

README.md

@@ -1,55 +1,116 @@
-
 # LEAF QA Automation Framework
 
-This README provides clear and simple guidelines for writing and maintaining test cases in the LEAF QA Automation Framework. It’s designed to keep everything consistent and easy to understand for everyone working on the project.
+This README provides guidelines for setting up, writing, and maintaining test cases in the LEAF QA Automation Framework. It ensures consistency and clarity for all team members working on test automation.
+
+## Prerequisites
+
+Before running tests, ensure you have the following installed:
+
+- [Node.js](https://nodejs.org/)
+- [npm](https://www.npmjs.com/) (Comes with Node.js)
+- [Playwright](https://playwright.dev/) (Installed globally or locally)
+
+### Install Dependencies
+
+Run the following command to install project dependencies:
+
+```sh
+npm install
+```
+
+### Install Playwright Browsers
+
+After installing dependencies, install Playwright browsers using:
+
+```sh
+npx playwright install
+```
+
+This ensures that all required browsers (Chromium, Firefox, WebKit) are downloaded and available for testing.
 
 ## Folder Structure
 
-- `tests/`: All test files are stored here.
-  - Example: `homepage.spec.ts`, `adminPanelFormEditor.spec.ts`
-- `global.setup.ts`: Handles global setup logic executed before tests.
-- `playwright.config.ts`: Configuration file for Playwright.
+The framework follows this folder structure:
+
+```
+LEAF-Automated-Tests/
+├── end2end/
+│   ├── tests/                 # Contains all test files
+│   │   ├── homepage.spec.ts   # Example test file
+│   │   ├── adminPanel.spec.ts # Example test file
+│   │   ├── global.setup.ts    # Handles global setup logic before tests
+│   ├── playwright.config.ts   # Configuration file for Playwright
+```
+
+## Running Tests
+
+### Execute All Tests
+
+Run all test cases using:
+
+```sh
+npx playwright test
+```
+
+### Run Tests in Headed Mode
+
+To run tests with a visible browser UI:
+
+```sh
+npx playwright test --headed
+```
+
+### Run a Specific Test
+
+To execute a specific test file, use:
+
+```sh
+npx playwright test end2end/tests/homepage.spec.ts
+```
+
+### Generate HTML Report
+
+To generate an HTML report after test execution:
+
+```sh
+npx playwright test --reporter=html
+```
+
+This will create a detailed test report in an HTML format that you can open in a browser.
 
 ## Test Writing Standards
 
 ### Organization
 
-- All test files go into the `tests/` folder.
-- Group related tests logically and use clear file names that explain the purpose of the tests.
+- All test files should be placed in the `tests/` folder.
+- Group related tests logically and use clear file names to indicate their purpose.
 
 ### Naming Conventions
 
 #### File Names
 
-- Use descriptive and meaningful file names.
-  - Example: `homepage.spec.ts` for homepage-related tests, `adminPanelSettings.spec.ts` for admin settings tests.
-- File names should indicate the functionality being tested.
-- Always use `.spec.ts` as the suffix for consistency and Playwright compatibility.
-
-### Matching Test Scripts with Test Names in Excel
-
-- Each test case written in the framework must match the corresponding test name in the Excel sheet.
-- The Excel sheet serves as a source of truth for test case documentation and steps.
-- Ensure that the test name in the script aligns exactly with the test name in the sheet to maintain traceability.
-- Example workflow:
-  1. Locate the test name in the Excel sheet.
-  2. Write the corresponding test case in the `tests/` folder.
-  3. Validate the implementation by cross-referencing the test steps from the Excel sheet.
+- Use descriptive and meaningful names.
+  - Example: `homepage.spec.ts`, `adminPanelSettings.spec.ts`
+- Always use `.spec.ts` as the suffix for Playwright compatibility.
 
 #### Test Names
 
-- Keep test names concise yet descriptive, clearly stating the intent of the test.
+- Keep test names concise yet descriptive.
   - Good Example: `shouldDisplayErrorMessageWhenLoginFails`
   - Poor Example: `errorTest`
-  - Avoid using long, overly complicated names.
 
 #### Variable and Function Names
 
 - Use camelCase for all variable and function names.
-- Names should describe the purpose clearly. Avoid generic names like `data` or `test1`.
   - Good Example: `loginButton`, `validateLoginPage`
   - Poor Example: `btn1`, `checkPage`
 
+### Matching Test Scripts with Test Names in Excel
+
+- Each test case written in the framework must match the corresponding test name in the Excel sheet.
+- The Excel sheet serves as the source of truth for test case documentation and steps.
+- Ensure that test names in scripts align exactly with those in the sheet to maintain traceability.
+
 ### Writing Test Cases
 
 - Use Playwright's `test` blocks to define test cases:
@@ -61,7 +122,7 @@ This README provides clear and simple guidelines for writing and maintaining tes
       await expect(page).toHaveTitle('Example Domain');
   });
   ```
-- Always include assertions to validate your results:
+- Always include assertions to validate results:
   ```typescript
   await expect(page.locator('#successMessage')).toHaveText('Form saved successfully');
   ```
@@ -71,86 +132,31 @@ This README provides clear and simple guidelines for writing and maintaining tes
       await page.goto('https://example.com/login');
   });
   ```
-- Ensure test cases are modular and only test one scenario at a time.
-  - Good Example: A test for successful login should not also check the homepage UI.
+- Keep test cases modular, testing one scenario at a time.
 
 ### Test Data Management
 
-- Don’t hardcode values. Store reusable test data in `.json` files or constants:
+- Avoid hardcoding values. Store reusable test data in `.json` files or constants:
+
   ```json
   {
       "username": "testUser",
       "password": "securePassword"
   }
   ```
-- For dynamic data, consider using libraries like `faker` to generate random inputs when needed.
-
-### Formatting and Indentation
-
-- Use consistent 2-space indentation across all files.
-- Ensure there’s a blank line between test cases for readability.
-- Break long lines at around 80-100 characters.
-- Organize imports at the top of the file, grouped by library and relative imports.
-
-#### Examples:
-
-**Consistent 2-Space Indentation:**
-
-```typescript
-import { test, expect } from '@playwright/test';
-
-test('should navigate to the homepage', async ({ page }) => {
-  await page.goto('https://example.com');
-  await expect(page).toHaveTitle('Example Domain');
-});
-```
-
-**Blank Line Between Test Cases:**
-
-```typescript
-test('should display login page', async ({ page }) => {
-  await page.goto('https://example.com/login');
-  await expect(page.locator('h1')).toHaveText('Login');
-});
-
-test('should allow user to log in', async ({ page }) => {
-  await page.goto('https://example.com/login');
-  await page.fill('#username', 'testUser');
-  await page.fill('#password', 'securePassword');
-  await page.click('#loginButton');
-  await expect(page).toHaveURL('https://example.com/dashboard');
-});
-```
-
-**Breaking Long Lines:**
-
-```typescript
-test('should display error message when login fails due to incorrect credentials', async ({ page }) => {
-  await page.goto('https://example.com/login');
-  await page.fill('#username', 'wrongUser');
-  await page.fill('#password', 'wrongPassword');
-  await page.click('#loginButton');
-  await expect(page.locator('#errorMessage'))
-    .toHaveText('Invalid username or password. Please try again.');
-});
-```
-
-**Organized Imports:** // NOT SURE IF WE NEED THIS !!!!
-
-```typescript
-// Library imports
-import { test, expect } from '@playwright/test';
-
-// Relative imports
-import { loginAsAdmin } from '../utils/auth';
-import { getTestData } from '../data/testData';
-```
+- Use libraries like `faker` to generate random inputs when needed.
 
 ### Comments
 
-- Add comments to explain parts of the test that aren’t obvious or are crucial to understand the test logic.
+- Add comments where necessary to explain complex test logic.
+
   ```typescript
   // Navigate to the login page
   await page.goto('https://example.com/login');
   ```
-- Avoid redundant comments that simply restate what the code does.
+- Avoid redundant comments that restate obvious actions.
+
+---
+
+This guide helps you set up and run tests efficiently using Playwright. For further details, refer to the [Playwright Documentation](https://playwright.dev/).
+