Skip to content

[ImageConverter] Extract check_input from process_image for focused unit tests #274

Description

@soswow

Summary

Extract the early validation at the start of ImageConverter::process_image (empty path, input existence / filesystem errors) into a dedicated function (working name: check_input) and invoke it from process_image. Unit tests should be able to exercise this validation path directly instead of relying only on the full process_image pipeline (configure, decode, write, etc.).

Background (for newcomers)

Today, checks live inline at the top of process_image in src/rawtoaces_util/image_converter.cpp (~empty filename, then std::filesystem::exists inside a try/catch). Tests such as test_last_error_message_empty_filename and test_last_error_message_file_not_found in tests/test_image_converter.cpp already call process_image, but splitting check_input makes it easier to test input validation only fast and deterministically, and keeps responsibilities clearer for future Dev Days contributors.

Where to look

  • src/rawtoaces_util/image_converter.cppImageConverter::process_image (opening block through filesystem validation).
  • include/rawtoaces/image_converter.h — whether check_input should be public for tests/bindings or test-only via a test helper pattern consistent with this project.
  • tests/test_image_converter.cpp — tests that assert status / last_error_message for invalid inputs.
  • tests/python/test_image_converter.py — Python tests that call process_image for invalid paths (behaviour should remain consistent unless deliberately changed with docs).

Suggested direction (not a prescription)

  • Factor the validation block into something like bool ImageConverter::check_input(const std::string &input_filename) (or free function if that fits the codebase better).
  • Update or add C++ tests that call check_input where it reduces reliance on the full conversion path.
  • Preserve existing observable behaviour for API consumers unless there is a documented reason to change it.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions