[Testing] Introduce Isolated Package-Level Unit Test Architecture

[aviralsaxena16]

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