🏗️ Framework Architecture (SOLID + POM)

Framework Architecture (SOLID + POM): Every piece you have written up to this tab (LoginSteps, LoginPage, LocatorRepository, env/ files) works on its own but is LOOSELY connected

Every piece you have written up to this tab (LoginSteps, LoginPage, LocatorRepository, env/ files) works on its own but is LOOSELY connected — like a shantytown that grew without a plan: every house digs its own well, wires its own electricity, no street numbering exists. The first 20 houses cause no trouble; by house 200, nobody knows whose water pipe runs under whose yard. A city zoning plan (architecture) is exactly what fixes this: shared infrastructure (a water/power grid = DriverFactory, ONE place managing the driver lifecycle), standard building codes (BasePage = the shared skeleton every Page class follows), neighborhood boundaries (a Steps class does ONLY orchestration, a Page class knows ONLY its elements). But if every piece already uses the same driver via DriverFactory.getDriver(), why open a separate architecture tab — don't the pieces already exist? Because EXISTING and being CORRECTLY RELATED are not the same thing: if pieces connect randomly (every Steps class creates its own driver, every Page class reinvents its own wait logic), one wait-strategy change in a 50-file project breaks 50 places. Comparison: in a poorly designed Java project, the difference between a "God Object" (one class that knows everything) and classes properly split along SOLID principles is exactly this — this tab will show you that difference through concrete Gauge/Selenium code. QA context: the REAL cause of a flaky test suite is often not a wrong locator but the absence of architecture — if a new QA engineer takes weeks to feel at home in the project, the fault usually lies in the architecture, not the newcomer.

Build Your Framework Step by Step

The 4 pieces below are the BIG PICTURE of the architecture you are about to build piece by piece in this tab. They all start locked — the first time you correctly finish that step's "Try It Yourself" practice, that piece flips from locked to BUILT. As you scroll down, you will complete the puzzle piece by piece.

🧭 Step 1 — The Big Picture: Framework Mindmap

The same architecture is shown here from five angles: first the main flow (who calls whom while a step runs), then the setup flow (how config reaches the driver), then parallel execution (why ThreadLocal exists), then the data-sharing scope (the DataStores), and finally a "does / does not" list for every class. Press ▶ Animate on the first two boxes to watch the flow advance step by step.

3️⃣ Parallel Execution — Why ThreadLocal?

The same DriverFactory class serves every thread, but thanks to ThreadLocal each thread holds its own WebDriver reference — when one thread calls quitDriver(), the others' sessions are NOT affected.

4️⃣ Data-Sharing Scope — The DataStores

5️⃣ Who Does What? — Class Responsibilities

In the architecture above, where does a Steps class (e.g. LoginSteps) get its WebDriver FROM?

It creates it itself with new ChromeDriver()

It gets it from ThreadLocal via DriverFactory.getDriver()

It reads it from the LocatorRepository class

It is manually defined at the top of every .spec file