The framework
Pandora is a model, not a black box.
Building your own automation framework is, almost always, a bad idea. We did it anyway — for a specific reason, and accepting what that entails.
A tool does something for you: it saves time and hides how things work. A model shows how to do it: it provides structure, imposes a way of organizing, and stays readable because its purpose is to be read. Pandora belongs to the second category, because it supports both our industrialization engagements and the technical material of our training courses.
What we are not showing yet
The Pandora repository and its technical documentation will be published separately. Until then, this page describes architecture principles, not a usage reference: we do not illustrate any API before it is publicly available.
This is a commercial drawback we accept. Publishing excerpts of an interface that may still change would produce exactly the outdated documentation we criticize in home-grown frameworks.
Three concrete consequences
A framework meant to be read is not designed like a framework meant to be used.
- D1
Explicit rather than magic
A few readable lines are better than an abstraction layer that guesses. Configuration by convention is comfortable until the day you want to step outside it.
- D2
The building blocks stay visible
You write Selenium and TestNG, not an intermediate language. What you learn stays useful elsewhere — including after leaving Pandora.
- D3
The report is a first-class citizen
A failing test must be understandable from the report, without rerunning it locally. It is a structural requirement, not an add-on.
What it enforces, what it leaves open
A framework that enforces everything becomes a straitjacket that teams work around. A framework that enforces nothing is just a collection of dependencies.
Enforced
- Separation between the intent of the test and knowledge of the interface: a selector has no place in a test.
- Data isolation between tests, without which no parallel run is reliable.
- Waits expressed as conditions rather than durations.
- A report structure that makes it possible to understand a failure without reproducing it.
Left open
- How suites are organized, which depends on the team.
- How page objects are split, which depends on the product.
- Whether to add test levels, which depends on the architecture.
Should you build your own?
In most cases, no. The article details the four conditions under which the answer changes, and what a framework should enforce rather than leave open.