12.08 — Ocarina in the testing industry#

Ocarina isn’t a better pytest, isn’t a better Robot Framework, isn’t a better Cypress. It’s structurally elsewhere. This chapter tries to explain the shift it represents and the head start it takes.

1. The current industry map#

Three big e2e tool families#

Family	Examples	Model
Text DSLs	Robot Framework, Cucumber + Gherkin	Permanent translation layer between text and code
Runner plugins	pytest-selenium, pytest-playwright, pytest-bdd	Grafted onto pytest, inherit its lifecycle
Vendor SaaS	BrowserStack, Sauce Labs, LambdaTest, Cypress Dashboard	Local runner + paid execution cloud

Three shared friction surfaces#

Friction	Manifestation
Marketing > Technical	Tools sold on demos, conferences, and oriented certifications. Hype drives adoption.
Vendor lock-in	Once adopted, refactor is costly, hostage taking.
Misplaced cognitive effort	Understanding the tool takes longer than doing the work.

2. Ocarina’s technical bet#

No text DSL → pure Python, embedded DSL.
No pytest plugin → integrated runner, absolute ISTQB fidelity.
No async/await → simplicity, Selenium-synchronous compatibility, no “geek tricks”.
No SaaS → all local, very dense core, white box.

None of these refusals is without reason. Each is justified by an explicit trade-off, and their combination produces a solution with no direct equivalent on the market.

3. The shift Ocarina represents#

First axis: return to the vocabulary of testing (ISTQB)#

The modern e2e industry has a mixed vocabulary: “pytest fixture”, “Gherkin step def”, etc. No business actor (ISTQB-certified functional tester) has this vocabulary in mind.

ISTQB	Ocarina
Test step	`act`
Test case	`Test`
Test suite	`TestSuite`
Campaign	`TestCampaign`
Cycle	`TestCycle`

It’s a shift: the code becomes readable by a functional tester.
Not just by a Python developer.

Second axis: make strict typing a business discipline#

No popular e2e framework has mypy strict = true as a prerequisite.
Ocarina does.

Errors are caught before execution.
The DSL is enforced by the compiler (mixing heterogeneous POMs in a drive_page is a mypy error, not a runtime error).
Maintenance is extremely guided (the type checker rechecks consistency after every change).

It’s a shift: we move the effort from when it breaks to when it’s written.

Third axis: make AI a first-class client#

Ocarina actively exposes to LLMs:

llms.txt, llms-full.txt.
CLAUDE.md, CLAUDE.slim.md.
40+ versioned skills (SKILL.md).
An entire e2e suite co-written by Claude (ocarina-with-ai-example).

No competing test framework has this AI surface.
It’s a shift: we design the DSL to be consumable by AI and human, not just human.

Fourth axis: make grammatical sovereignty a promise#

Ocarina doesn’t ship a fixed DSL. It ships:

ChainRunner[T] as the extension point.
“Project adapter” pattern as convention.
Closure-based composition rather than inheritance.

Each project writes its own framework on top of the framework (act, match_page, TestSuite adapter, TestCampaign adapter, EnvGetters).

It’s a shift: we give the grammar back to the project, rather than fully entrusting it to the tool.

4. Head start#

Where Ocarina is ahead#

Axis	Estimated lead vs the industry
Strict typing in e2e	5-10 years (most frameworks stay `Any`-everywhere)
AI-first	2-5 years (others start exposing MCP/AI hooks, though with a questionable approach)
Embedded vs text DSL	Permanent (philosophical difference, no catch-up planned)
ISTQB vocabulary	Permanent (philosophical difference)
Auditability (1 runtime dep)	Permanent (philosophical difference)
ROP as core	5-10 years (most use classic exceptions)

Where Ocarina isn’t ahead#

Axis	Reality
Notoriety	None in the mainstream. Target audience: advanced testers.
Plugin ecosystem	Deliberately minimal. The Python ecosystem is one of the industry’s largest and can be directly embedded in an Ocarina project without friction.
Cloud-as-a-service	None (deliberate). On the other hand, Ocarina is natively built for horizontal scaling.
Multi-language	Python only (deliberate).

Vision#

Ocarina starts from the following hypotheses:

The market will shift toward fewer platforms, more clean code, more internal development. The Sanity → Markdown evolution (Lee Robinson, Cursor, December 2025, confirmed by Sanity themselves in their public response) is a signal.
AI will replace frameworks with long learning curves. Why learn Robot Framework if Claude can write a Python test in 5 seconds? That’s what the author calls a Juicero press.
Functional testers will be revalued because they’ll carry the business vision, while AI carries the technique.

If these three hypotheses hold (and there are signals they will), Ocarina is exactly in the right place.

If they don’t, Ocarina will remain a niche project, but the author accepts that explicitly ("It’s my car").

5. The market — honest analysis#

Short term (2026-2028)#

Ocarina will remain niche. No enterprise tooling, no SLAs, no paid support.
Adoption by consultants who want a portable tool ("Ocarina in your pocket").
Adoption by functional testers who want to deliver rather than waste time on endless “geek tricks”.
Adoption by solo devs / boutique agencies who write their own tests.
Adoption by security-paranoid teams that can’t use SaaS.

Medium term (2028-2032)#

Three scenarios:

Scenario A — Ocarina stays niche#

500-2000 users.
Small but tight-knit community.
No market influence.
The author doesn’t give a damn. The adventure continues. The code stays auditable.

Scenario B — Ocarina influences without being adopted#

More likely. Ocarina’s ideas (strict typing in e2e, ISTQB vocabulary, AI-first) diffuse and are picked up by more popular frameworks.
Ocarina isn’t massively adopted, but becomes the intellectual reference that gets cited.
Like Hindley-Milner for programming languages: few people write it in practice, but all modern languages are heirs.

Scenario C — Ocarina is widely adopted#

Less likely. Requires a triggering event.
If it happens: Ocarina will have waited for its moment.

Long term (2032+)#

Ocarina is built to outlive its author. The code is small, audited, MIT. Fork it, pick it up, maintain it.

6. Qualitative comparison with some alternatives#

Aspect	Ocarina	Robot Framework	Playwright	Cypress	Selenium IDE
Text DSL	❌ Pure Python	✅ .robot files	❌ Pure TS	❌ Pure JS	✅ Steps file
Runner plugin	❌ Internal runner	❌ Internal runner	✅ Jest/Mocha	❌ Internal runner	(UI)
Strict typing (mypy/strict)	✅ ALL	❌ (Python typing still rare)	⚠️ TS support but POMs often `any`-typed	⚠️ JSDoc rare	❌
ROP	✅ Central	❌ Exceptions	❌ Exceptions	❌ Exceptions	❌
AI-first	✅ documented, technology designed for it from the start	❌	⚠️ Playwright CodeGen	⚠️ Third-party AI tooling	❌
ISTQB vocabulary	✅ strict	⚠️ partial	❌ Jest-like	❌ describe/it	❌
Vendor lock-in	❌ None	❌ None	⚠️ Microsoft	⚠️ Cypress.io	⚠️ Selenium project
Auditability	✅ 1 runtime dep	❌ Internal ecosystem	❌ Massive Node deps	❌ Cypress runtime	⚠️
Async/await	❌ Refused	❌	✅ Mandatory	✅ Mandatory	❌
Parallelization	✅ ThreadPool + Semaphore + simple parallelization strategy, customizable by the user, no magic	⚠️ pabot	✅ JS Workers	✅ Parallel CI	❌
Native anti-flakiness approach	✅ Parallelization + Test cloning + Fine AI analysis	❌	❌	❌	❌

7. Values Ocarina carries#

Test code:

must be readable by functional testers (ISTQB vocabulary)
must first and foremost be a cross-team communication tool (same)
must be readable by AI (strict typing + strict linter + well-defined grammar)
must remain maintainable (very strong content/form separation)
must be driven by the test strategy without compromise (huge skill battery)
must be auditable and portable (a single dep, MIT, copyable)
doesn’t need a platform to work
doesn’t have to reinvent the wheel (back to fundamentals)