Hi @jan-petr and @1brahimmohamed,
Following the successful implementation of:
• Phase 1 - CI pipeline #21
• Phase 2 - End-to-end regression fixtures #22
• Phase 3 - Automated coverage visibility #33
I would like to propose the next structural improvement to our testing architecture.
The Problem:
Currently, our CI relies entirely on FastAPI-level integration tests that execute generate_report() as a black box. While this ensures end-to-end safety, it makes it difficult to:
• Isolate failures in internal utilities (unit conversions, DICOM parsing, metadata normalization)
• Provide fast feedback for contributors modifying low-level logic
• Scale testing efficiently as DCE/DSC modalities are introduced
As CI complexity grows, relying solely on full NIfTI/DICOM fixtures will increase runtime and reduce contributor velocity.
The Proposal:
Introduce an isolated package-level unit testing structure inside package/tests/ to:
• Test internal utilities independently of FastAPI
• Provide sub-second validation of core logic
• Establish a scalable structure for future module-specific tests
Initial Target:
Start with deterministic unit tests for:
• unit_conversion_utils.py
• dcm_utils.py
CI Enhancement:
Extend the CI matrix to execute package unit tests separately from backend integration tests, ensuring fast failure detection.
This directly fulfills the GSoC objective of preparing a structure “so that further testing files for all modules can be easily uploaded.”
If you agree, I will submit a PR establishing the package-level test architecture and initial high-impact unit coverage.
Best,
Aviral
Hi @jan-petr and @1brahimmohamed,
Following the successful implementation of:
• Phase 1 - CI pipeline #21
• Phase 2 - End-to-end regression fixtures #22
• Phase 3 - Automated coverage visibility #33
I would like to propose the next structural improvement to our testing architecture.
The Problem:
Currently, our CI relies entirely on FastAPI-level integration tests that execute generate_report() as a black box. While this ensures end-to-end safety, it makes it difficult to:
• Isolate failures in internal utilities (unit conversions, DICOM parsing, metadata normalization)
• Provide fast feedback for contributors modifying low-level logic
• Scale testing efficiently as DCE/DSC modalities are introduced
As CI complexity grows, relying solely on full NIfTI/DICOM fixtures will increase runtime and reduce contributor velocity.
The Proposal:
Introduce an isolated package-level unit testing structure inside package/tests/ to:
• Test internal utilities independently of FastAPI
• Provide sub-second validation of core logic
• Establish a scalable structure for future module-specific tests
Initial Target:
Start with deterministic unit tests for:
• unit_conversion_utils.py
• dcm_utils.py
CI Enhancement:
Extend the CI matrix to execute package unit tests separately from backend integration tests, ensuring fast failure detection.
This directly fulfills the GSoC objective of preparing a structure “so that further testing files for all modules can be easily uploaded.”
If you agree, I will submit a PR establishing the package-level test architecture and initial high-impact unit coverage.
Best,
Aviral