Skip to content

Roadmap

Jump to bottom
idel fuschini edited this page Jul 24, 2026 · 2 revisions

Idelium Roadmap

Objective

Transform Idelium into a modern test automation framework with:

  • a simple, stable proprietary DSL;
  • execution based on W3C WebDriver;
  • progressive support for WebDriver BiDi;
  • exports and integrations with external ecosystems;
  • a modular, testable, and maintainable architecture.

Guiding principles

  1. The language is independent from the browser engine.
  2. The backend must use open standards: W3C WebDriver first, WebDriver BiDi later.
  3. The user experience must stay simple for both test authors and maintainers.
  4. Every DSL feature must have a clear AST representation.
  5. Every step must be validatable, debuggable, and serializable.

Tracking epics

Phase 1 — Project foundations

Objectives

  • Define the product scope.
  • Establish the DSL grammar.
  • Separate parsing, AST, and execution engine responsibilities.

Deliverables

  • Versioned DSL specification in a human-readable format.
  • Canonical AST.
  • Initial parser.
  • Minimal runtime for executing basic commands.

Minimum DSL commands

  • Open page.
  • Click.
  • Enter text.
  • Wait for element.
  • Assert visibility/text.
  • Navigate forward/back.
  • Capture screenshot.
  • Handle basic errors.

Acceptance criteria

  • A simple script can be parsed and executed end-to-end.
  • Syntax errors are clear.
  • The AST is stable and serializable as JSON.

Phase 2 — Core execution engine

Objectives

  • Implement the DSL execution engine.
  • Introduce a WebDriver adapter.
  • Make the system reliable on Chrome, Firefox, and Edge.

Deliverables

  • W3C WebDriver adapter.
  • Browser session management.
  • Step-by-step execution.
  • Structured logging.
  • Configurable timeouts.
  • Controlled retries for selected actions.

Features to include

  • Explicit waits.
  • CSS and XPath selector handling.
  • Frame and window handling.
  • File upload.
  • Download handling.
  • Alert handling.
  • Screenshot capture on failure.

Acceptance criteria

  • Tests run on at least two browsers.
  • The engine clearly distinguishes network, locator, and assertion errors.
  • Reports show step, duration, and status.

Phase 3 — A truly useful DSL

Objectives

  • Make the language readable for non-experts.
  • Add high-value constructs.
  • Reduce boilerplate.

Recommended constructs

  • Variables.
  • String interpolation.
  • if blocks.
  • Simple loops.
  • Reusable steps/macros.
  • Helper functions.
  • Advanced assertions.
  • Parameters from CLI or files.

Deliverables

  • Stable DSL v1 syntax.
  • Documentation with examples.
  • Basic language linting.
  • Human-readable error messages.

Acceptance criteria

  • A medium-complexity script can be written without duplicated code.
  • The language remains compact but expressive.
  • A complete getting-started guide exists.

Phase 4 — Observability and debugging

Objectives

  • Make test failures easy to understand.
  • Add execution tracing and artifacts.

Deliverables

  • Step-level traces.
  • Structured JSON logs.
  • Automatic screenshots on failure.
  • HTML and JSON reports.
  • Artifact export for CI.

Useful features

  • Step timeline.
  • Duration per step.
  • Locator used.
  • Current page.
  • Browser session state.
  • Run attachments.

Acceptance criteria

  • A failure can be diagnosed without opening the test code.
  • Reports are readable by both humans and CI systems.

Phase 5 — Stability and scalability

Objectives

  • Prepare Idelium for real team usage.
  • Reduce flakiness.
  • Support parallel executions.

Deliverables

  • Parallel runs.
  • Session isolation.
  • Setup/teardown hooks.
  • Support for different environments.
  • Configuration management for development, staging, and production.

Stability improvements

  • Centralized wait strategy.
  • Selector resilience.
  • Controlled re-runs only for transient failures.
  • Browser/session health checks.

Acceptance criteria

  • A suite with multiple tests runs in parallel.
  • Results are reproducible.
  • Multi-environment configuration is simple.

Phase 6 — Modern ecosystem integration

Objectives

  • Make Idelium a platform, not only a runtime.
  • Integrate Idelium with CI/CD and external tools.

Deliverables

  • Complete CLI.
  • GitHub Actions integration.
  • GitLab CI integration.
  • JUnit/XML output.
  • JSON export for external tooling.
  • Plugin API for extensions.

Possible exports

  • JSON AST.
  • JUnit test results.
  • Markdown report.
  • HTML report.
  • Intermediate debugging script.

Acceptance criteria

  • Idelium can run in CI without manual intervention.
  • Results are compatible with standard pipeline tools.

Phase 7 — WebDriver BiDi and advanced capabilities

Objectives

  • Add modern capabilities beyond classic WebDriver.
  • Support browser events, console logs, network observation, and advanced diagnostics.

Deliverables

  • Optional BiDi adapter.
  • Event listeners.
  • Console log capture.
  • Network observation.
  • Better debugging hooks.

Use cases

  • Tests that listen to browser events.
  • Network request validation.
  • JavaScript error capture.
  • SPA flow diagnostics.

Acceptance criteria

  • BiDi is optional but well integrated.
  • Advanced features do not break the core WebDriver execution path.

Phase 8 — Packaging, release, and governance

Objectives

  • Make the project adoptable and sustainable.
  • Avoid regressions.
  • Define a public product version.

Deliverables

  • Semantic versioning.
  • Automated changelog.
  • Release notes.
  • Public roadmap.
  • Contribution policy.
  • Automated regression tests.

Recommended governance

  • Versioned DSL specification.
  • Backward compatibility for existing tests.
  • Deprecations with a clear time window.
  • RFC process for every major change.

Acceptance criteria

  • Every release is repeatable and documented.
  • Breaking changes are rare and announced.

Recommended priorities

P0

  • Parser.
  • AST.
  • Base runtime.
  • W3C WebDriver adapter.
  • Simple test execution.

P1

  • Assertions.
  • Timeouts.
  • Screenshots.
  • Reports.
  • CLI.

P2

  • Variables.
  • Macros/reuse.
  • CI integration.
  • Parallel runs.

P3

  • BiDi.
  • Plugin system.
  • Advanced exports.
  • Future-proof multi-backend architecture.

Practical definition of “modern”

To be modern today, Idelium should:

  • rely on W3C WebDriver as the minimum execution foundation;
  • plan WebDriver BiDi as the evolution path;
  • avoid being tied to a proprietary IDE format;
  • export results and metadata in standard formats;
  • keep a proprietary DSL, but make it documented and versioned.

Suggested positioning statement

Idelium is a domain-specific test automation framework with a proprietary DSL and a W3C WebDriver execution backend, designed for modern browser automation and extensibility.

Final goal

Idelium should not become “another Selenium IDE”.

It should become an automation framework with its own readable, modern language and a standards-based execution backend.

Next operational step

Implement in this order:

  1. DSL spec v1.
  2. Canonical AST.
  3. Parser.
  4. WebDriver runtime.
  5. CLI.
  6. Reporting.
  7. CI.
  8. BiDi.

Idelium is open source. Contributions, issue reports, and documentation improvements are welcome through the Idelium GitHub repositories.

Clone this wiki locally