What is Ocarina?

Ocarina was designed to make automated browser-based tests as simple as possible, while giving its user total control.

Another one!

Them

Most testing frameworks were built in a world where the barrier between "those who code" and "those who define tests" was real and structural.

Robot Framework tried to work around it with a DSL (Domain Specific Language), complete with its own format and its own plugin ecosystem. In doing so, RF imposes its own standards by default: that's the immediate cost of its promise.

Cucumber tried the same with Gherkin: a "natural" language that, in practice, constrains everyone without truly freeing anyone. Cost: a permanent translation layer, Gherkin/code desynchronization.

All of them bet on the same thing: hiding complexity to bridge the gap between profiles.
Result: non-technical people remain spectators, and technical people end up trapped in a tool they would never have chosen.

The biggest cost is a race to the bottom: fewer options, and a "flexibility" that can only be achieved by fighting your tools rather than using solutions.

There's no use pulling on the rope we've each been given if what lies at the center is just a Gordian Knot.

Us

Better alone than in bad company.

Ocarina bets on the opposite: this barrier will disappear. This is a non-debate around which everyone has tied a noose with needlessly complicated tools, mistaking them for solutions. Impact: operational disaster the moment a need arises that can't be expressed within a "framework" that is NOT truly generic.

And the worst part: all these technologies will keep evolving in the same direction. NONE of them will make this shift, because it would require a paradigm change, a return to fundamentals that directly contradicts their entire value proposition.

Yet what remains is the need for test code that is readable, traceable and flexible in its most raw form.

With AI, and tools like Claude Code, this bet grows stronger every day.
The bridge between technical and non-technical people is no longer an abstraction layer.

It's AI itself. AI that works on raw data.

The cultural problem

There is another blind spot, rarely named: methodology.

ISTQB, where are you?

The ISTQB and professional testers have spent decades building a precise, battle-tested vocabulary: test cycles, campaigns, test suites, test cases, test steps. A clear hierarchy, designed to organize, trace and drive software quality.

Automated tools have largely ignored this legacy.

pytest, Jest, Mocha... all are hybrid mixes where testers must learn to think like developers, and where nobody truly speaks the same language.

This "two-language method" is a failure.

Back to basics

Ocarina makes no such compromise.

Its structure is modeled directly and exclusively on the tester's methodology. Every concept in the code maps to a domain concept in testing. No borrowing, no repurposing, no "close enough."

And because Ocarina commits to this bet all the way: it is entirely autonomous. No pytest plugin. No forced integration into a third-party ecosystem. Ocarina is batteries-included, it needs nothing else to operate, and that is a deliberate choice.

The real pain point

About "creativity"

Everyone obsesses over the how: interfaces, abstractions, "pretty" DSLs.
Meanwhile, the why disappears.

Ocarina makes the opposite choice.

Its entire design and this Holy Book are focused on the why: on real problems.
Not on an abstraction to use "however you like."

As for the how?
The answer is simple: Ocarina is dense, immediately operational and strict. Built so that both humans and LLMs can understand its core and usage without friction.

What's the science?

Here, everything rests on static foundations:

• types,
• generics,
• functional programming.

Ocarina makes its misusing difficult by design: the compiler shall prevail.

Just algebra.

📖 Algebra comes from the Arabic الجبر (al-jabr), which means "the reunion of broken parts" or "the reduction of fractures."

Most tools start from human grammar to supposedly "formalize."
Then comes the realization that a machine can't read it as-is.
So, let's pile on "adapters."

We don't call that formalization but wishful thinking.

Ocarina obviously does the opposite.
That's what makes Ocarina stable and extensible at the same time.

Vision

Sovereign grammar

What if delegating your grammar to "standards" was never a good idea in the first place?

The real gap with E2E testing is not imposing the "best" Newspeak.
Short answer: Ocarina is extensible. Any verb and conjunction can be created, all governed by strict rules that keep the whole thing deeply consistent.

What remains is to guarantee traceability and robustness.

Born from the field

In Ocarina, every step is observable.
The error path is explicit. The test report emerges naturally from the code.

No over-engineering. No unnecessary dependencies.
Just something small, readable, and built to last.

The most powerful thing is that Ocarina invents nothing: Ocarina returns to fundamentals.

Adoption

In the most extreme cases: Ocarina doesn't need to be installed.
Copy it, adapt it, run it.
No dependency to audit.

For teams constrained by security policies: the code is small, auditable in an afternoon. Nothing hidden. The only external dependencies live in the post-execution plugins and if one of them doesn't fit, it can be removed without breaking anything else.

In practice, a consultant can show up at a client site with Ocarina in their pocket, almost without asking anyone's permission.

People don't grow weary, outdated strings wear them down.

And that is precisely why it exists: to give testers back their independence.
All of this, in a jewel of synthesis.

Игорь Казанова