claude-3.5-sonnet.md

I'll help you create a comprehensive project structure for E2E automation testing that follows best practices and incorporates all your required technologies. Let me plan this out first.

e2e-automation/
├── .github/
│   └── workflows/
│       ├── main.yml                 # Main CI workflow
│       └── scheduled-tests.yml      # Scheduled test runs
│
├── src/
│   ├── fixtures/                    # Playwright test fixtures
│   │   ├── auth.fixture.ts
│   │   └── api.fixture.ts
│   │
│   ├── pages/                       # Page Object Models
│   │   ├── base.page.ts            # Base page with common methods
│   │   └── components/             # Reusable page components
│   │       ├── header.component.ts
│   │       └── footer.component.ts
│   │
│   ├── features/                    # Cucumber feature files
│   │   ├── auth/
│   │   │   ├── login.feature
│   │   │   └── registration.feature
│   │   └── checkout/
│   │       └── payment.feature
│   │
│   ├── step-definitions/            # Cucumber step definitions
│   │   ├── auth.steps.ts
│   │   └── checkout.steps.ts
│   │
│   ├── api/                        # API testing modules
│   │   ├── clients/                # API clients
│   │   │   ├── base.api.ts
│   │   │   └── auth.api.ts
│   │   └── schemas/               # API response schemas
│   │       └── auth.schema.ts
│   │
│   ├── helpers/                    # Utility functions
│   │   ├── test.helper.ts
│   │   └── api.helper.ts
│   │
│   └── types/                      # TypeScript type definitions
│       └── api.types.ts
│
├── test-data/                      # Test data files
│   ├── users.json
│   └── products.json
│
├── config/                         # Configuration files
│   ├── playwright.config.ts        # Playwright configuration
│   └── cucumber.js                 # Cucumber configuration
│
├── reports/                        # Test reports directory
│   └── .gitkeep
│
├── package.json
├── tsconfig.json
├── .env.example                    # Environment variables template
├── .gitignore
└── README.md

Key configuration files content:

# package.json:
{
  "name": "e2e-automation",
  "version": "1.0.0",
  "scripts": {
    "test": "cucumber-js",
    "test:api": "cucumber-js --tags @api",
    "test:e2e": "cucumber-js --tags @e2e",
    "test:parallel": "cucumber-js --parallel 3",
    "report": "generate-cucumber-report",
    "lint": "eslint . --ext .ts",
    "format": "prettier --write \"**/*.{ts,json,md}\""
  },
  "dependencies": {
    "@cucumber/cucumber": "^latest",
    "@playwright/test": "^latest",
    "typescript": "^latest"
  }
}

playwright.config.ts:
import { PlaywrightTestConfig } from '@playwright/test';

const config: PlaywrightTestConfig = {
  testDir: './src',
  timeout: 30000,
  retries: 2,
  workers: 3,
  use: {
    baseURL: process.env.BASE_URL,
    screenshot: 'only-on-failure',
    video: 'retain-on-failure',
    trace: 'retain-on-failure'
  },
  projects: [
    {
      name: 'Chrome',
      use: { browserName: 'chromium' }
    },
    {
      name: 'Firefox',
      use: { browserName: 'firefox' }
    }
  ]
};

export default config;

.github/workflows/main.yml:
name: E2E Tests

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Run tests
        run: npm run test
      - name: Upload test results
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: reports/

I've created a comprehensive project structure that follows the Page Object Model pattern and incorporates all your required technologies. Here are some key aspects of the structure:

1. Test Organization:

   • Features and step definitions are separated for better maintainability
   • Page Objects are organized with a base page and reusable components
   • API tests are structured with separate clients and schemas

2. Key Features:

   • Playwright fixtures for handling common setup/teardown
   • Support for parallel test execution
   • API and E2E tests separation using Cucumber tags
   • Comprehensive GitHub Actions CI setup
   • Environment-based configuration

3. Best Practices:

   • Type definitions for better TypeScript support
   • Separate test data management
   • Configurable reporting
   • Reusable helpers and utilities
   • Clear separation of concerns

4. Added Benefits:

   • Support for multiple browsers in configuration
   • Automatic screenshot and video capture on failure
   • Retry mechanism for flaky tests
   • Parallel execution support
   • Artifact upload in CI

Would you like me to explain any specific part of the structure in more detail or provide example code for any of the components?

gemini-2.0-pro-exp-02-05.md

Okay, here's a well-considered project structure for an E2E automation testing project using Playwright, TypeScript, Cucumber, and the specified technologies and design patterns. I've focused on scalability, maintainability, and best practices.

Project Structure Rationale

Before diving into the structure, let's outline the why behind the choices:

• Separation of Concerns: Each directory has a specific purpose, making it easy to find and modify code related to a particular aspect of the testing framework.
• Testability: The structure facilitates unit testing of utility functions and components, although the focus is on E2E.
• Scalability: The organization allows for easy addition of new features, tests, and pages as the application under test grows.
• Readability: Clear naming conventions and organization make the project understandable for new team members.
• Reusability: Components (page objects, fixtures, helpers) are designed to be reused across multiple tests.
• Maintainability: Changes to the application UI are ideally isolated to page objects, minimizing the impact on test scripts.
• Reporting and CI/CD Integration: Dedicated folders for reports and CI/CD configurations.
• Configuration Management: Centralized configuration for different environments.

Project Structure

e2e-automation-project/
├── .github/
│   └── workflows/                # GitHub Actions workflows
│       └── main.yml               # CI/CD pipeline definition
├── api/                      # API tests
│    └──tests/                   # All test cases
│        └── example.api.spec.ts    # Example test suite file
│    └──fixtures/                # All fixtures related to API
│        └── apiRequestContext.ts  # API request context Fixture file
├── e2e/                        # End-to-end (UI) tests
│   ├── features/               # Cucumber feature files
│   │   ├── login.feature       # Feature: Login
│   │   └── checkout.feature    # Feature: Checkout
│   ├── step_definitions/       # Cucumber step definitions (glue code)
│   │   ├── login.steps.ts      # Steps for login.feature
│   │   └── checkout.steps.ts   # Steps for checkout.feature
│   ├── support/                # Shared code, hooks, custom commands, utilities
│   │   ├── hooks.ts            # Cucumber hooks (before, after, etc.)
│   │   ├── world.ts          # Custom World for better state
│   │   ├── env.ts              # Environment variables loading and management
│   │   └── utils.ts            # Utility functions (e.g., date formatting, random data generation)
│   ├── pages/                  # Page Object Model classes
│   │   ├── basePage.ts         # BasePage class (common methods and properties)
│   │   ├── loginPage.ts        # Page object for the login page
│   │   ├── homePage.ts         # Page object for the home page
│   │   ├── productPage.ts      # Page object for product pages
│   │   └── checkoutPage.ts     # Page object for the checkout process
│   ├── fixtures/                 # Playwright fixtures
│   │   ├── customFixtures.ts        # Example: Custom Fixtures
│   │   └── test.ts                 # Fixtures export and config
│   └── data/                   # Test data (JSON, CSV, etc.)
│       ├── users.json          # User credentials for data-driven tests
│       └── products.json       # Product data
├── reports/                    # Test reports (generated by Playwright/Cucumber)
├── .gitignore                  # Specifies intentionally untracked files
├── package.json                # Node.js project metadata and dependencies
├── playwright.config.ts        # Playwright configuration file
├── tsconfig.json               # TypeScript compiler configuration
├── cucumber.json		        # Configuration file for cucumber
└── README.md                   # Project documentation

Detailed Explanation of Key Directories and Files:

• .github/workflows/: This directory houses your GitHub Actions workflows. main.yml (or a similarly named file) defines your CI/CD pipeline. It will specify triggers (e.g., push to main, pull request), build steps (install dependencies, run tests), and reporting steps (publish test results).

• api/: This is a dedicated space for your API tests.

  • api/tests: Your API test files using Playwright's API testing capabilities.
  • api/fixtures: Specific Playwright Fixtures for API request.

• e2e/: This is the heart of your E2E test suite.

  • features/: Contains your Cucumber feature files, written in Gherkin syntax. Each .feature file describes a specific feature or functionality of your application. Good feature files are concise, user-centric, and describe the what and why, not the how.

  • step_definitions/: Contains the TypeScript code that implements the steps defined in your feature files. These "glue code" files connect the human-readable Gherkin steps to Playwright actions. Each step definition should be small, focused, and reusable.

  • support/: This directory holds shared code and utilities.

    • hooks.ts: Defines Cucumber hooks, which are functions that run before and after scenarios, steps, or features. Common uses include setting up test data, taking screenshots on failure, and cleaning up after tests.
    • world.ts: Defines a custom World for managing shared state and functionality within your Cucumber steps.
    • env.ts: Loads environment variables (e.g., from .env files) and makes them available to your tests. This is crucial for managing different environments (development, staging, production).
    • utils.ts: Contains reusable utility functions that are not specific to a particular page or feature (e.g., generating random strings, formatting dates, parsing data).

  • pages/: Implements the Page Object Model (POM).

    • basePage.ts: A base class that contains common methods and properties shared by all page objects (e.g., navigation, waiting for elements, common assertions).
    • loginPage.ts, homePage.ts, etc.: Each page object represents a specific page or component of your application. It encapsulates locators (selectors) and methods that interact with that page. This is where the bulk of your UI interaction code lives. Keep methods focused on user actions (e.g., login(username, password), addToCart(productName)).

  • fixtures/: Defines Playwright fixtures, which are reusable test setup and teardown functions.

  • customFixtures.ts: Contains your project custom fixtures.

  • test.ts: Configure and export your custom fixtures.

  • data/: Stores test data for data-driven testing. This could include JSON files with user credentials, product data, or any other data needed for your tests. Using external data files makes your tests more maintainable and allows you to easily run the same tests with different sets of data.

• reports/: This directory is where Playwright and Cucumber will generate test reports. You'll typically configure the report format (HTML, JSON, etc.) in playwright.config.ts and cucumber.json.

• playwright.config.ts: The main configuration file for Playwright. This is where you define settings like:

  • Browsers to run tests on (Chromium, Firefox, WebKit)
  • Viewport size
  • Test timeout
  • Reporting options
  • Base URL
  • Global setup and teardown
  • Use custom fixtures
  • Define your different test projects

• tsconfig.json: Configuration for the TypeScript compiler.

• cucumber.json: Configuration settings related specifically to Cucumber. You can define:

  • Path to the step definitions and feature files
  • Formatter for report generation
  • Tags

• package.json: Defines your project's dependencies (Playwright, Cucumber, TypeScript, etc.) and scripts (e.g., test, test:e2e, test:api).

Key Best Practices Implemented:

• Page Object Model (POM): All UI interactions are encapsulated within page objects.
• Data-Driven Testing: Test data is stored externally in the data/ directory.
• Playwright Fixtures: Reusable setup and teardown are handled by Playwright fixtures.
• Cucumber BDD: Tests are written in a human-readable format using Gherkin.
• TypeScript: Provides strong typing, better code completion, and improved maintainability.
• Environment Variables: Sensitive information and environment-specific settings are managed through environment variables.
• CI/CD Integration: The .github/workflows directory is set up for GitHub Actions.
• Clear Naming Conventions: Consistent and descriptive names for files, directories, classes, methods, and variables.
• BasePage: Common functionality is contained inside the BasePage and extended by other page objects.

This comprehensive structure provides a solid foundation for building a robust and maintainable E2E automation test suite. Remember to adapt it to your specific project needs and application architecture. Good luck!

o1.md

Below is an example of an organization-standard project structure for end-to-end (E2E) automation testing using Playwright, TypeScript, Cucumber, and Node.js. It includes API tests, follows the Page Object Model, uses data-driven tests, and incorporates Playwright fixtures. It also features a sample GitHub Actions setup.

---

1. Thought Process / Planning

1.1 Separation of Concerns

• src/pages: Page Object Model classes (one file per page or logical group).
• tests/features: BDD feature files (Cucumber .feature files).
• src/steps: Cucumber step definitions and hooks.
• src/apis: API client utilities or API-specific page objects for REST/GraphQL testing.
• tests/data: JSON or CSV files for data-driven testing.
• src/fixtures: Custom Playwright test fixtures or global fixtures to set up test context.
• config: Configuration files (Playwright config, environment, or additional custom configs).
• .github/workflows: CI pipeline configuration (GitHub Actions).

1.2 Page Object Model (POM) Principles

• Each Page or Component is encapsulated in a class.
• Each class exposes methods for interactions and state checks, keeping your step definitions clean and readable.

1.3 Data-Driven Tests

• Keep test data in tests/data.
• Use a library or custom logic to read JSON/CSV data.
• In step definitions or hooks, load data from these sources to drive your scenarios.

1.4 Playwright Fixtures

• Create custom fixtures (e.g., user fixture, authenticated fixture, etc.) in src/fixtures.
• Reuse fixtures within your step definitions or page objects to avoid duplication and simplify test setup.

1.5 API Tests with Playwright

• Store API-specific utilities in src/apis and tests in either:
  • tests/features/api with separate .feature files for API scenarios, or
  • tests/api-tests if you prefer a code-only test approach (Playwright test runner).

1.6 GitHub Actions

• Store your CI configuration under .github/workflows.
• The typical workflow includes install, build, test steps, and optional concurrency settings or environment matrix.

---

2. Example Folder Structure

Below is a sample folder and file layout. Folders are explained in detail afterward.

e2e-automation-project/
├── .github/
│   └── workflows/
│       └── e2e-tests.yml             # GitHub Actions workflow for CI
├── config/
│   ├── environment.ts                # Environment-specific configs (env URLs, credentials, etc.)
│   └── playwright.config.ts          # Main Playwright config
├── src/
│   ├── pages/
│   │   ├── BasePage.ts               # Base class with shared page methods
│   │   └── LoginPage.ts              # Example login page POM
│   ├── apis/
│   │   └── UserApi.ts                # Example API client or utility
│   ├── fixtures/
│   │   └── user.fixture.ts           # Example fixture for user setup/teardown
│   ├── steps/
│   │   ├── hooks.ts                  # Cucumber hooks (beforeAll, afterAll, etc.)
│   │   ├── common.steps.ts           # Shared or common step definitions
│   │   └── login.steps.ts            # Step definitions for login feature
│   └── support/
│       ├── cucumber.config.ts        # Cucumber configuration & setup
│       └── logger.ts                 # Example logger or helper utility
├── tests/
│   ├── features/
│   │   ├── login.feature             # BDD feature for login workflow
│   │   └── user-management.feature   # Example user management feature
│   ├── data/
│   │   ├── login-data.json           # Example JSON data for data-driven login tests
│   │   └── user-data.json            # Additional user data examples
│   └── api-tests/
│       └── user-api.spec.ts          # Example code-based API test (Playwright Test runner)
├── .gitignore
├── package.json
├── tsconfig.json
└── README.md

2.1 .github/workflows/

• e2e-tests.yml: Defines how GitHub Actions will build, test, and report on your project.

2.2 config/

• playwright.config.ts: Main configuration for the Playwright test runner (e.g., browsers, timeouts, reporters, etc.).
• environment.ts: Contains environment variables, endpoints (dev, staging, production), or other environment-based configurations.

2.3 src/pages/

• BasePage.ts: A base class that other page objects can extend, providing shared methods like navigateTo(), waitForElement(), etc.
• LoginPage.ts: A page object modeling your login page, including selectors and methods such as enterUsername(), enterPassword(), and submitLogin().

2.4 src/apis/

• UserApi.ts: Example module for interacting with user-related REST or GraphQL endpoints. This keeps your API logic separate from your UI logic, but still within the same codebase.

2.5 src/fixtures/

• user.fixture.ts: Example fixture that sets up or tears down user data before a test. Fixtures can also manage browser contexts or authentication tokens if needed.

2.6 src/steps/

• hooks.ts: Cucumber hooks that run before/after all tests or scenarios (e.g., global test setup, teardown).
• common.steps.ts: Shared steps used across multiple features, such as logging in or navigating between pages.
• login.steps.ts: Specific step definitions for the login.feature.

2.7 src/support/

• cucumber.config.ts: Configuration for Cucumber (e.g., default timeouts, custom parameter types, etc.).
• logger.ts: Custom logger or helper utilities for logging test results, debugging info, etc.

2.8 tests/features/

• login.feature: BDD scenario definitions for login flows.
• user-management.feature: Example feature file for user management scenarios.

2.9 tests/data/

• login-data.json: Data for data-driven login tests (e.g., multiple username/password combos).
• user-data.json: Additional user details for CRUD-based tests.

2.10 tests/api-tests/

• user-api.spec.ts: A code-based test for API endpoints using the Playwright test runner. Alternatively, you can have BDD-based API tests with .feature files in tests/features/api.

2.11 Root Files

• .gitignore: Standard Node/TypeScript ignoring rules (node_modules, dist, coverage reports, etc.).
• package.json: Project metadata, dependencies (Playwright, Cucumber, TypeScript, etc.), scripts for test runs.
• tsconfig.json: TypeScript configuration for compilation targets, strictness, etc.
• README.md: Documentation on how to install, configure, and run the tests.

---

3. Additional Best Practices

1. TypeScript Strictness
   Enable strict mode in tsconfig.json to catch type errors early.

2. Use Linting & Formatting

   • Consider adding ESLint + Prettier for code style, enforced in CI.

3. Version Control

   • Keep all test artifacts and test data in Git.
   • Avoid committing secrets or sensitive data; use environment variables or secret managers.

4. Configurable Environment

   • Use dotenv or environment variables to switch between dev/staging/prod URLs and credentials.

5. CI/CD

   • Keep the pipeline fast by splitting tests if needed (e.g., UI vs. API in parallel).
   • Use caching for node_modules in GitHub Actions to speed up builds.

6. Reporting

   • Use built-in Playwright reporters (HTML, JUnit) or custom reporters.
   • Publish reports as GitHub Actions artifacts for easy viewing.

7. Scalability

   • Group tests into logical packages or subfolders if they grow large.
   • Use a consistent naming scheme for features, pages, and data files.

---

4. Conclusion

This folder structure is a foundation you can customize based on your team’s needs. By separating pages, steps, data, fixtures, and configs, you maintain clear boundaries and ensure your E2E test suite remains maintainable, scalable, and readable. Additionally, including GitHub Actions config out-of-the-box ensures continuous integration, enabling quick feedback on test results for every push or pull request.

o3-mini-high.md

Below is an example of an organization-standard project structure for an E2E automation framework that leverages Playwright, TypeScript, Cucumber, API testing with Playwright, Node.js, and GitHub Actions. This design adheres to best practices and incorporates the Page Object Model, data-driven testing, and Playwright fixtures.

Feel free to adjust folder names and file contents as your team’s conventions evolve.

---

Project Structure Overview

project-root/
├── .github/
│   └── workflows/
│       └── e2e-tests.yml            # GitHub Actions CI workflow for running tests
├── node_modules/                   # Installed Node packages (auto-generated)
├── reports/                        # Test reports (HTML, JSON, etc.)
├── src/
│   ├── api/
│   │   ├── endpoints/              # API endpoint wrappers / helper modules
│   │   │   └── userEndpoints.ts    # Example: User-related API calls
│   │   └── tests/                  # API tests using Playwright
│   │       └── userApiTests.spec.ts
│   ├── config/
│   │   └── config.ts               # Environment & global test configuration (URLs, credentials, etc.)
│   ├── data/
│   │   └── testData.json           # Data sets for data-driven tests (or CSV/Excel files as needed)
│   ├── fixtures/
│   │   └── customFixtures.ts       # Custom Playwright fixtures for test setup/teardown
│   ├── pages/                      # Page Object Model implementations
│   │   ├── BasePage.ts             # Base class for common page functions
│   │   ├── HomePage.ts             # Example page object
│   │   └── LoginPage.ts            # Example page object for login functionality
│   ├── features/                   # Cucumber feature files (Gherkin syntax)
│   │   ├── login.feature           # Feature file for login scenarios
│   │   └── apiTesting.feature      # Feature file for API testing scenarios
│   ├── steps/                      # Cucumber step definitions (mapped to features)
│   │   ├── login.steps.ts          # Step definitions for login.feature
│   │   └── api.steps.ts            # Step definitions for apiTesting.feature
│   ├── support/                    # Cucumber support files and global hooks
│   │   ├── hooks.ts                # Before/After hooks (set up/tear down steps)
│   │   └── world.ts                # Custom World definition for sharing context between steps
│   └── utils/                      # Helper functions, logging, and common utilities
│       └── helpers.ts
├── playwright.config.ts            # Playwright configuration file (testDir, reporter, projects, etc.)
├── cucumber.js                     # Cucumber configuration (features location, formatters, etc.)
├── tsconfig.json                   # TypeScript compiler options
├── package.json                    # Project metadata, dependencies, and scripts
└── .env                            # Environment variables (sensitive data, URLs, etc.)

---

Folder & File Responsibilities

1. .github/workflows/

   • Contains CI/CD pipelines. For example, e2e-tests.yml sets up the Node.js environment, installs dependencies, and executes the test suite on every push or PR.

2. src/api/

   • endpoints/: Wraps REST API calls into reusable modules (using Playwright’s API testing features).
   • tests/: Contains API-specific test cases. Use the same reporting and fixture strategy as UI tests.

3. src/config/

   • Holds configuration details such as base URLs, environment variables, timeouts, and credentials. These can be imported into your tests and fixtures.

4. src/data/

   • Stores external test data used for data-driven tests. This helps decouple data from test logic and allows easier maintenance.

5. src/fixtures/

   • Contains custom Playwright fixtures to manage test context, such as logging in a user, creating test data, or initializing browser contexts.
   • Example: A fixture that logs into your application once per test suite to speed up tests.

6. src/pages/

   • Implements the Page Object Model. Each page (or component) has its own class that encapsulates selectors and functions (actions, validations) that can be reused across multiple tests.
   • Example: LoginPage.ts might include methods like fillUsername(), fillPassword(), and submit().

7. src/features/

   • Contains Gherkin feature files written in plain language (e.g., login.feature). This allows non-developers to review and even write test scenarios.

8. src/steps/

   • Maps each Gherkin step from the feature files to actual implementation code. Use descriptive naming conventions to make maintenance easier.

9. src/support/

   • Includes hooks (e.g., beforeAll, afterAll) and a custom World object to share context (data, variables) between steps.
   • Centralizes the configuration for Cucumber (global hooks, error handling, etc.).

10. src/utils/

    • Contains utility functions and common helper methods that can be reused across pages, steps, and fixtures.

11. playwright.config.ts

    • Central configuration for Playwright. Set parameters like test directories, timeouts, retries, reporters, and integration with custom fixtures.

12. cucumber.js

    • Configures the Cucumber framework (e.g., where to find feature files, step definitions, and output formatting).

13. tsconfig.json

    • TypeScript configuration ensuring proper compilation for your test suite.

14. package.json

    • Manages dependencies (Playwright, Cucumber, TypeScript, etc.) and scripts to run tests (e.g., npm test).

15. .env

    • Stores sensitive or environment-specific information (never check into source control unless properly secured).

---

Best Practices Incorporated

• Separation of Concerns:
  Code is organized by its purpose (e.g., pages vs. API endpoints vs. test data) to enhance maintainability and scalability.

• Page Object Model (POM):
  All UI interactions are encapsulated in page classes, reducing code duplication and easing maintenance when UI changes.

• Data-Driven Testing:
  Externalizing test data (in the /data folder) allows tests to run against multiple data sets without modifying test logic.

• Playwright Fixtures:
  Custom fixtures in /fixtures help manage complex test setups and reduce repetitive code in your test files.

• Cucumber Integration:
  Feature files in /features (written in Gherkin) paired with step definitions in /steps allow for behavior-driven development and easy collaboration with non-developers.

• CI/CD Integration:
  The .github/workflows directory ensures tests are automatically run on commits/PRs, enforcing code quality and stability.

• Modularity and Reusability:
  Shared utilities and configuration files make the framework modular and easier to extend.

---

This structure serves as a robust starting point for a large-scale, maintainable, and scalable E2E automation framework using Playwright, TypeScript, and Cucumber. Adjust or extend folders as needed to match your team’s workflow and specific project requirements.

prompt.md

Create an organization standard project structure for E2E Automation Testing.

MUST HAVE:

""" Tech Stack:

• Playwright
• Typescript
• Cucumber
• API Tests Using Playwright
• Node.js
• Github Actions

Design Pattern:

• Page Object Model
• Data Driven Tests
• Playwright Fixtures """

Think thorougly about the project structure and the best practices before you start. Once you have a plan, create a project structure and share it.