The previous commit fixed the FrameIO/LDF diagram by labeling the
ldf-lookup edge as "duck-typed" without defining the term. This commit
adds a dedicated section explaining what duck typing means in this
codebase, why both architectural seams (FrameIO's ldf injection and the
lin fixture's adapter swap) rely on it, and the Python idioms behind it.
Content covers:
- The "walks like a duck" slogan and what it means in code: shape of
used methods is the contract, not the class.
- Example 1 — FrameIO and the untyped `ldf` parameter: shows the
contract (single .frame() call) and the absence of any
`from ecu_framework.lin.ldf import LdfDatabase`. Includes the
counter-example of what nominal typing would have meant for
module dependencies and testability.
- Example 2 — the lin fixture and adapter polymorphism: same idiom,
with LinInterface providing the nominal anchor.
- EAFP ("Easier to Ask Forgiveness than Permission") as the supporting
Python idiom, contrasted with LBYL.
- The trade-off section: implicit contracts and runtime-only errors,
and how the codebase mitigates them.
Cross-linked from 24_test_wiring.md's `lin` polymorphism-boundary
discussion so readers of either doc can navigate to the explanation.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Documentation Index
A guided tour of the ECU testing framework. Start here:
01_run_sequence.md— End-to-end run sequence and call flow02_configuration_resolution.md— How configuration is loaded and merged03_reporting_and_metadata.md— How test documentation becomes report metadata11_conftest_plugin_overview.md— Custom pytest plugin: hooks, call sequence, and artifacts04_lin_interface_call_flow.md— LIN abstraction and adapter behavior (Mock, MUM, and the deprecated BabyLIN)05_architecture_overview.md— High-level architecture and components06_requirement_traceability.md— Requirement markers and coverage visuals07_flash_sequence.md— ECU flashing workflow and sequence diagram08_babylin_internals.md— BabyLIN SDK wrapper internals and call flow (DEPRECATED)16_mum_internals.md— MUM (Melexis Universal Master) adapter internals and call flow17_ldf_parser.md— LDF parser,ldffixture, and per-framepack/unpackhelpers18_test_catalog.md— Per-test catalog: purpose, markers, hardware needs, expected resultDEVELOPER_COMMIT_GUIDE.md— What to commit vs ignore, commands09_raspberry_pi_deployment.md— Run on Raspberry Pi (venv, service, hardware notes)10_build_custom_image.md— Build a custom Raspberry Pi OS image with the framework baked in12_using_the_framework.md— Practical usage: local, hardware (MUM, or the deprecated BabyLIN), CI, and Pi13_unit_testing_guide.md— Unit tests layout, markers, coverage, and tips14_power_supply.md— Owon PSU control, configuration, tests, and quick demo script15_report_properties_cheatsheet.md— Standardized keys for record_property/rp across suites19_frame_io_and_alm_helpers.md— Hardware-test helpers:FrameIO(generic LDF I/O) andAlmTester(ALM_Node domain), plus thetests/hardware/_test_case_template.pystarting point20_docker_image.md— Containerizing the framework: mock-only CI image, hardware-passthrough image, the Melexis-package obstacle, compose & CI examples21_yocto_image_for_raspberry_pi.md— Building a Yocto image that turns a Raspberry Pi into a self-contained test bench (BSP layout, recipes, network/USB config, deploy & maintenance)23_config_loader_internals.md— Howecu_framework/config/loader.pyis implemented: merge semantics, type coercion, schema quirks, and the PSU side-channel24_test_wiring.md— How tests are wired to the framework: fixture topology, session lifecycle, the polymorphism boundary onlin, and the playbook for adding a new framework component
Related references:
- Root project guide:
../README.md - Full framework guide:
../TESTING_FRAMEWORK_GUIDE.md - BabyLIN placement and integration:
../vendor/README.md(deprecated; only relevant for legacy rigs) - MUM source scripts and protocol details:
../vendor/automated_lin_test/README.md - PSU quick demo and scripts:
../vendor/Owon/