Repository navigation
Magento Template Coverage Roadmap
Help Magento frontend developers see which template expressions and interactions their tests exercise, directly in the IDE, for Luma and Hyvä storefronts.
Status: proposed; not yet implemented. Start with a feasibility milestone before committing to full delivery. This roadmap concerns coverage of users' Magento projects and is separate from coverage and quality of the plugin itself.
- PHP and JavaScript coverage do not, by themselves, explain which Magento template bindings or frontend interactions were exercised.
- Browser and CI reports can point to generated assets, container paths, or templates overridden by a theme, making uncovered source difficult to find.
- A template appearing on a page does not prove that its event handlers or conditional content were tested.
- Missing measurements and outdated results can look like uncovered code or misleadingly complete coverage.
- Validate a Luma project with Knockout bindings, virtual bindings, Magento binding shorthand, and supported Underscore expressions.
- Validate a Hyvä project with Alpine expressions, event handlers, conditional content, and inline JavaScript in PHTML templates.
- Demonstrate navigation and highlighting in the actual theme override used by the measured storefront.
- Verify the experience in PhpStorm and WebStorm, including coexistence with native PHP and JavaScript coverage.
- Publish a support matrix describing which measurements are available, which require source mappings, and which remain unsupported.
Milestone acceptance: real reports map to the correct source files and expressions; uncovered interactions remain visible; unknown or stale results are not presented as reliable coverage. Hyvä mapping must be demonstrated, not inferred from Luma support.
- Import supported template coverage reports generated locally or in CI without requiring a particular collector or test runner.
- Document an extensible report contract so additional tools can provide source locations, measurement types, hit counts, and optional source fingerprints and run context.
- Reuse native PHP Clover and JavaScript coverage support where available; evaluate adapters for common formats such as LCOV and Istanbul where they add useful Magento integration.
- Clearly state what each imported format can show. Generic line coverage must not be interpreted as template-expression or interaction coverage when that information is absent.
- Support configurable project-root and container/CI path mappings, with a clear list of unresolved or ambiguous files.
- Allow users to select, reload, replace, and clear imported reports. Report malformed or unsupported data without disturbing the editor.
- Highlight covered, partially covered, and unexecuted lines or expressions in PHTML and browser HTML templates, according to the evidence supplied by the report.
- Explain highlights on hover: what was measured, hit counts when available, and the source run or report.
- Navigate to the next uncovered expression or interaction from a coverage summary.
- Distinguish unmeasured, unsupported, unresolved, and stale results from measured zero-hit code.
- Provide a simple visibility toggle and accessible, theme-aware markers that coexist with IDE diagnostics and native coverage.
- Resolve module templates, theme overrides, and parent-theme fallback to the measured original file.
- Preserve frontend/adminhtml area, theme, and store-view context when reports provide it; make missing context visible when it prevents reliable resolution.
- Map deployed, bundled, or transformed assets to their source using supplied source mappings. Avoid guessing between multiple matching templates.
- Support Luma's Knockout and supported template-expression syntax, including multiple expressions on one line.
- Support Hyvä's Alpine expressions and inline JavaScript where reports retain reliable original PHTML locations.
- Keep PHP execution, JavaScript execution, template-expression execution, and template observation distinguishable within mixed-language files.
- Detect source changes using fingerprints or equivalent report evidence, and mark or hide stale highlights until compatible results are loaded.
- Treat a missing file or report entry as unknown unless the report explicitly defines it as part of the measured scope with zero hits.
- Show branch outcomes only when the report measures them. Executing a condition is not proof that both outcomes were exercised.
- Keep template observation separate from expression and event-handler execution. A rendered page is not proof that all interactions were tested.
- Merge compatible runs only, preserving source identity and measurement scope; do not average percentages or mix incompatible theme/source versions silently.
- Keep separate totals for PHP, JavaScript, template expressions, and observed templates, with clear denominators and exclusions.
- Browse coverage by module, theme, area, directory, and file, with filters for uncovered and partially covered items.
- Focus on changed templates where source-control and report data allow a reliable comparison.
- Identify the scenarios or tests that exercised an expression when the imported report includes that information.
- Keep large Magento projects responsive through background import and highlighting limited to relevant open files.
- Provide an illustrated guide covering local and CI imports, path mapping, Luma and Hyvä examples, and the meaning of each coverage state.
- Real Luma and Hyvä examples, plus fixtures for PHTML, HTML, mixed PHP/JavaScript, theme inheritance, and multiple bindings per line.
- Covered and zero-hit expressions, partially covered lines, unobserved templates, and unsupported constructs.
- Missing vendor sources, container paths, ambiguous overrides, changed files, Unicode/line-ending differences, and incompatible report merges.
- IDE checks confirming correct highlight placement, cleanup after clearing reports, coexistence with native coverage, and responsive use on large reports.
- A second report adapter or independently produced compatible report demonstrating that the feature is not coupled to one producer.
The initial scope is importing and presenting coverage evidence. Collecting runtime data remains the responsibility of compatible external tools. Building a universal collector or proving visual correctness is outside this roadmap. Coverage indicates execution or observation as labelled; it does not prove that test assertions are sufficient.
Native Coverage tool-window integration is an investigation item. The essential outcome is reliable Magento-aware source highlighting and navigation across the supported IDEs.
