A well-organized folder structure is critical at scale. Here is the production project structure:
selenium-framework/
├── pom.xml
├── testng.xml
├── src/
│ └── test/
│ ├── java/
│ │ └── com/practice/
│ │ ├── base/
│ │ │ └── BaseTest.java ← WebDriver setup/teardown
│ │ ├── pages/
│ │ │ ├── BasePage.java ← Common page methods
│ │ │ ├── banking/
│ │ │ │ ├── LoginPage.java
│ │ │ │ ├── DashboardPage.java
│ │ │ │ └── TransferPage.java
│ │ │ ├── shopping/
│ │ │ │ ├── ShopHomePage.java
│ │ │ │ ├── CatalogPage.java
│ │ │ │ ├── CartPage.java
│ │ │ │ └── CheckoutPage.java
│ │ │ └── components/
│ │ │ ├── HeaderComponent.java
│ │ │ └── SidebarComponent.java
│ │ ├── tests/
│ │ │ ├── banking/
│ │ │ │ ├── LoginTests.java
│ │ │ │ ├── DashboardTests.java
│ │ │ │ └── TransferTests.java
│ │ │ └── shopping/
│ │ │ ├── CatalogTests.java
│ │ │ ├── CartTests.java
│ │ │ └── CheckoutTests.java
│ │ └── utils/
│ │ ├── ConfigReader.java
│ │ └── DataProviders.java
│ └── resources/
│ ├── config.properties
│ └── test-data/
│ └── login-data.csvThe key insight: the tests/ folder mirrors the pages/ folder. If you have pages/banking/LoginPage.java, you have tests/banking/LoginTests.java. This makes it obvious where to find things.
Q: Describe your automation framework structure.
A: My framework uses POM with a layered architecture. BasePage provides common methods — click, type, getText, waits. Page objects are organized by module (banking, shopping), each extending BasePage with private locators and public methods. Shared components like header and sidebar are separate classes composed into pages. Test classes mirror the page structure and extend BaseTest, which handles WebDriver initialization with ThreadLocal for parallel execution. Utilities handle config reading and data providers. Test data is in external CSV/Excel files under resources.
Key Point: Organize: base/ for setup, pages/ for page objects, components/ for shared UI, tests/ mirroring pages/, utils/ for helpers.