Project Structure and tech stack

🧾 Overview

This project automates vendor integration processes for our web platform using Playwright and TypeScript. It follows a modular structure inspired by Feature-Sliced Design (FSD) to promote scalability, maintainability, and separation of concerns. The automation scripts ensure that vendor workflows—such as onboarding, configuration, and verification—are consistently tested and validated in an automated and repeatable manner.

🛠 Tech Stack

• Playwright – Browser automation and end-to-end testing.
• TypeScript – Strongly typed JavaScript for better tooling and maintainability.
• Feature-Sliced Design (FSD) – Organizing code by features and layers for better domain alignment.
• Node.js – Runtime environment.

📁 Project Structure

src/
│
├── constant/       # Centralized constants (e.g. selectors, status codes)
├── fsd/            # Feature-Sliced Design: feature-oriented structure
├── data/           # Mock data, test datasets, or fixture files
├── config/         # Configuration files (env setups, test settings)
├── tests/          # Test cases and test suites using Playwright
├── types/          # Global and shared TypeScript type definitions
├── services/       # API services, vendor-specific integrations
└── helper/         # Utility functions, common logic used across features

🧩 Directory Descriptions

src/constant/

This directory contains centralized constants used across the automation project to avoid magic strings and ensure consistency, Purpose :

• Promotes reusability and consistency.
• Helps avoid hardcoding strings throughout the codebase.
• Enables easier updates (e.g., adding a new vendor only in one place).

src/fsd/

The fsd (Feature-Sliced Design) folder organizes the project by vendor-specific feature domains. Each subfolder under fsd represents an integration with a different vendor implementation. This structure allows for high modularity, test isolation, and reusability of shared business logic.

Folder Structure Overview

src/fsd/
├── globaltix/            # Extends shared logic from `vendor`
├── google_reserve/       # Custom logic & API for Google Reserve integration
├── gyg/                  # Custom logic & API for GetYourGuide integration
├── kkday/                # Extends shared logic from `vendor`
├── openrice/             # Extends shared logic from `vendor`
├── royal_orchid_plus/    # Extends shared logic from `vendor`
├── spark_love/           # Extends shared logic from `vendor`
├── vendor/               # Base logic shared across similar vendors
└── v5/                   # V5 API that used by AOA and TagThai

Shared Logic: vendor/

The vendor/ folder contains common logic for vendors using the same API schema. Vendors such as kkday, openrice, royal_orchid_plus, spark_love, and globaltix extend this logic. Common contents:

• api/ – Shared request definitions
• services/ – Common service handlers
• types/ – Shared TypeScript types/interfaces
• tests/ – Base test logic and reusable assertions This pattern avoids duplication and allows API key or config overrides per vendor while retaining core logic.

src/data/

The data/ directory holds static datasets and mock API responses used to support automation workflows for vendor integration. These files provide mappings, reference data, and snapshots of vendor-related entities to drive and validate test scenarios.

📄 File Descriptions

• gygOptionId.json Contains mappings between GetYourGuide option IDs and restaurant package IDs. Used to verify linkage during GYG integration.
• packagesData.json Holds package data retrieved from the vendor API. Used to simulate or validate the result of fetching a specific restaurant package.
• restaurant.ts Exports a list of restaurant IDs along with their inventory sources. Used for scoping which vendors or sources are involved in integration flows.
• restaurantData.json Stores restaurant detail data fetched from the vendor API. Supports mock testing and validation of restaurant-level information.
• rwgPackageId.json Maps restaurant IDs to their restaurant package IDs for restaurants integrated with Google Reserve. Enables sync and validation processes.
• tags.json Defines tags associated with packages or restaurants. Supports logic that depends on tag-based matching or categorization.

src/config/

Contains Playwright test configurations and environment-related files:

src/tests/

All test files and test suites. Organized by this docs

[

docs.google.com

https://docs.google.com/spreadsheets/d/1Y_8a--aD5w0T8udGIhuDkSI2dnujIyMiJmacR7Kq1Ao/edit?userstoinvite=hanggar%40hungryhub.com&sharingaction=manageaccess&role=writer&pli=1&gid=923674532#gid=923674532

](https://docs.google.com/spreadsheets/d/1Y_8a--aD5w0T8udGIhuDkSI2dnujIyMiJmacR7Kq1Ao/edit?userstoinvite=hanggar%40hungryhub.com&sharingaction=manageaccess&role=writer&pli=1&gid=923674532#gid=923674532)

src/types/

Centralized TypeScript types and interfaces:

• API schemas
• Vendor structures

src/services/

Wrapper modules for API calls and external service interactions:

• Test Runner
• Function to find master data

src/helper/

Shared utility functions:

• Date formatting
• Currency
• HTTP Request