Question 1

Why is the Page Object Model built on classes?

Accepted Answer

Because a class keeps data and behaviour together: locators are fields, user operations are methods. The benefits: (1) a locator is defined once — a UI change is fixed in a single file; (2) the test reads in business language (await loginPage.login(...)) instead of being littered with CSS selectors; (3) the constructor takes the page context once, so no method has to re-receive it; (4) extends lets shared behaviour live in a BasePage. Add this: POM is not mandatory — plain helper functions are enough for a small suite; the real goal is reducing duplication and the cost of change.

Question 2

What is this bound to in JavaScript and when does it get "lost"?

Accepted Answer

In a regular function this depends on how it is called — whoever calls it becomes this: in api.get(), this is api. When the method is detached (const f = api.get; f() or map(api.get)) there is no calling object left and in strict mode this becomes undefined — that is where it is "lost". An arrow function has no this of its own: it takes it from the lexical scope where it was written, which is what makes it safe in callbacks. The fixes: wrap in an arrow, bind, or write the class field as an arrow. Close with one sentence: in a regular function this is decided at call time, in an arrow at declaration time.

Question 3

How do you choose between inheritance and composition in a POM?

Accepted Answer

I decide by the relationship: "X is a kind of Y" means inheritance, "X has a Y" means composition. In practice I keep one level of BasePage inheritance (navigation, common waits, a screenshot helper) and embed everything else as components — header, modal, table, filter panel. The reason: in a deep hierarchy it gets hard to find where a method is defined, a small parent change breaks dozens of pages, and the same component cannot be reused across two different hierarchies. Composition lets you attach a component to any page. One more argument: in TypeScript composition gives a clearer contract at the interface level.

Question 4

How do you handle encapsulation in a page object — should locators be public or private?

Accepted Answer

By default locators are private: a test calling fill directly on loginPage.emailInput defeats the purpose of the POM — the logic scatters back into the test file. Outward I expose action methods (login, submitOrder) plus a few locator getters needed for assertions (errorBanner(), rowByName(name)). That balance matters: lock everything down and each new check forces a new POM method; open everything up and the POM degrades into a locator dictionary. The principle: actions as methods, assertion targets as getters, internal details (URL, token, helper selectors) private. In TypeScript private protects at compile time while # protects at runtime — I pick based on the team's convention.

Construct	What it does	Example in a POM
constructor(page)	prepares locators when the object is created	this.submit = page.getByRole('button')
extends / super()	inherits from another class; super() calls the parent constructor	class LoginPage extends BasePage
#privateField	visible only inside the class	#baseUrl — tests cannot touch it
static method	called without an instance	TestUser.random()
arrow class field	binds this to the instance permanently	get = (path) => fetch(...)

Classes and OOP basics

📚 Sources and documentation