Skip to content

Public demo indicator consistency fix

Ticket #335: Demo indicator consistency fix on the public showcase and test-suite reinforcement
Type: Bug Fix / Business Analysis / Test Automation
Affected Component: code_source_simule/flask_app.py, templates/demo_index.html, tests/test_demo.py, requirements.txt, docs/tests/index.md, docs/tests/demo.md, docs/fr/tests/index.md, docs/fr/tests/demo.md, coverage.xml, docs/reports/report.xml, docs/reports/report.jsonl


1. Context and Symptoms

The public demo page (/demo) uses mock data, but it must remain credible for visitors evaluating the product without full access. A careful review revealed four business inconsistencies that reduced this credibility:

  • the Top 10 Performers card could show a losing holding, and Bottom 10 Performers could show a gaining holding;
  • the same ticker could appear in both Closest to 52-Week High and Closest to 52-Week Low;
  • the same ticker could appear in both high-target and low-target analyst indicators, with targets sometimes unrealistically far (up to several dozen percent) from the displayed price;
  • the Moving Against Expectations card displayed a mixed French/English subtitle while the demo page is expected to be fully English.

2. Objective

Fix these four inconsistencies without adding new mock holdings, because the existing test suite already enforces a 10-holding maximum for the demo sample.

3. Implemented Solution

3.1 - Strict separation of gainers and losers
Top/Bottom cards in _build_demo_dashboard_context() now filter gainers and losers separately before sorting, instead of splitting one sorted list into upper/lower slices, which could produce overlap.

3.2 - Mutual exclusivity for 52-week cards
Each ticker is now assigned to exactly one card (near annual high or near annual low), based on the shortest distance between current price and each threshold. A ticker can no longer appear in both cards.

3.3 - Recalibration of demo analyst targets
Mock Lowest Price Target and Highest Price Target values were tightened to remain within a realistic 0-10% range around the displayed price, while preserving coherence with an_haut/an_bas values already used by 52-week cards.

3.4 - English-only subtitle
The Moving Against Expectations subtitle was fully translated to English (Holding Gain Change (Gain %) / Investor Sentiment) to remove the last residual French fragment from the demo page.

4. Test-Suite Assessment and Reinforcement

Before closing the correction, the existing test suite (tests/test_demo.py) was evaluated to verify whether it already locked these four rules. Result: it validated general rendering, the 10-holding cap, and tooltip links, but did not explicitly lock sign constraints, card exclusivity, or displayed-target coherence.

A dedicated new test case (tc-demo14) was therefore added to permanently enforce these four business rules by reading computed data from _build_demo_dashboard_context() directly, instead of relying only on rendered HTML text checks. No existing test was removed or modified.

The pytest-json-report dependency, missing from requirements.txt despite planned usage in manage.py, was added to make report regeneration reproducible in the local environment.

5. Validation and Outcome

  • Demo-focused suite: 14 tests passed.
  • Full suite: 254 tests passed, 3 warnings.
  • Application-code coverage (code_source_simule/*) recalculated: 82.37%.
  • Regenerated reports: coverage.xml, docs/reports/report.xml, docs/reports/report.jsonl.
  • Test-report documentation (EN/FR) synchronized with the new test case and updated execution results.

6. Lessons Learned

  1. Visual-render coverage does not replace business-rule coverage. Existing tests validated card visibility, but not whether card data respected expected coherence rules (sign, exclusivity, value ranges). Tests must lock business rules directly, not only presentation.
  2. Demo-data consistency can be fixed without adding new mock holdings by redesigning allocation logic (shortest-distance assignment) instead of increasing sample size, which would have violated the existing test cap.
  3. Token cost: 290.57 Copilot AI credits consumed for this session, corresponding to an estimated raw value of $2.91. This cost remains marginal versus the time saved (about 2 hours) to correct and lock four distinct business rules in a single session.