🗂️ JSON Locator Repository

JSON Locator Repository: A JSON locator repository is a library's card catalog: the books (elements) sit on shelves, but WHICH book is on WHICH shelf is recorded in one central c

A JSON locator repository is a library's card catalog: the books (elements) sit on shelves, but WHICH book is on WHICH shelf is recorded in one central catalog (locators.json). When books move, you don't walk every shelf — you update the catalog card, and EVERYONE using the catalog automatically goes to the right shelf. With @FindBy that knowledge is baked into code: when a locator changes you edit the .java file, recompile, and redeploy. But if @FindBy already centralizes locators in Page Objects, why add a JSON layer — an extra file plus reader code, for what? For this: turning locators from CODE into DATA opens three doors — (1) fixes without compilation: an id changed in the UI, you fix one JSON line, no jar rebuild; (2) non-coding team members can update locators; (3) the same locator set can be read by multiple frameworks/tools (a Java and a JS test project can share one JSON). Java comparison: it is exactly the decision to use a .properties/config file instead of hard-coded Strings — the locator version of "which values should move from code to configuration?". Also know the honest QA cost: the compiler CANNOT catch a typo in JSON — a wrong field name in @FindBy is a compile error, a wrong key in JSON explodes at runtime. That is why the repository class must throw an exception with a CLEAR message on a missing key instead of returning silent null — the LocatorRepository in this tab does exactly that.

📄 Step 1: Design the locators.json Structure

We use a two-level dictionary: page name → element name → {type, value}. The type field is the By strategy name (id, css, xpath, name...), and value is the selector itself. The structure is deliberately kept FLAT: "clever" schemas nesting 5 levels deep kill readability. The file goes under src/test/resources — Maven automatically puts it on the test classpath, so we read it from the classpath rather than a file path and tests behave identically on every machine, CI included.

Micro Lab: Locator strategy practice

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

📦 Step 2: The LocatorDef POJO + Reading with Jackson

We use Jackson to turn JSON into Java (add com.fasterxml.jackson.core:jackson-databind to pom.xml). The target type is Map > — the outer Map holds pages, the inner one holds elements. Jackson needs a TypeReference to deserialize into a generic Map: because of Java's type erasure, Map.class alone cannot carry the inner types — the TypeReference anonymous subclass is the standard Jackson trick that carries generic info to runtime.

Looking Up a Locator by Page+Element Key

LocatorRepository.get("loginPage", "usernameInput") — the lookup begins with two keys.

Outer Map: page lookup

The "loginPage" key is looked up in the outer Map; if missing, an error lists the available pages.

Inner Map: element lookup

The "usernameInput" key is looked up in that page's inner Map; if missing, it lists the available elements.

Converted to a By object