Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: prepare code for a new image processor #30

Merged
merged 8 commits into from
Nov 8, 2024

Conversation

knarewski
Copy link
Contributor

Background
I'm prototyping libvips-based Morandi on a separate branch in hope of improving its memory profile and performance. We want to provide ability to render using either Pixbuf of Vips within a single version of Morandi.

Problems

  1. Both libraries will need to pass certain tests to be considered correct, but we'd like to avoid duplication
  2. Certain tests rely on implementation details of Pixbuf

Solutions

  1. Extract the shared operations into a shared_examples group (unchanged within a dedicated commit)
  2. Break dependency on the implementation details

Notes

  • Due to moving a lot of lines I suggest reviewing with whitespaces ignored
  • It turned out that the image matcher was overwriting some output when using shared examples, that was addressed by using spec scope ids
  • I've also included some minor adjustments which I've noticed along the way

The spec is now visually comparing the images so it does not need a mock
The exact computed height is 243.75. Pixbuf seems to trim the fraction, but 244 feels more accurate
…mpty

Some libraries may treat it as unknown type (Vips), the others as corrupt image (Pixbuf)
Vips-based processor will not support all the pixbuf operations, this commit extracts the ones which we plan to support
into a shared_examples block, so that they can be reused when the time comes
One of the background styles (dominant) was not included; the quality is actually an integer
In case of shared examples, line number may be duplicated leading to overwriting the images from other specs
@knarewski knarewski requested a review from MrLukeSmith November 7, 2024 16:12
Comment on lines 54 to 56
(expect { process_image }).to(raise_error do |err|
err.is_a?(Morandi::UnknownTypeError) or err.is_a?(Morandi::CorruptImageError)
end)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(expect { process_image }).to(raise_error do |err|
err.is_a?(Morandi::UnknownTypeError) or err.is_a?(Morandi::CorruptImageError)
end)
expect { process_image }.to raise_exception(Morandi::UnknownTypeError, Morandi::CorruptImageError)

Untested, but couldn't you do something like this instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second argument of raise_exception is an expected error message :-)

       Expected raised exception #<Morandi::CorruptImageError "Image file “sample/sample.jpg” contains no data">
                        to match #<Morandi::UnknownTypeError Morandi::CorruptImageError>

Alternatively I can do the following if you find it nicer (?)

        expect { process_image }.to raise_error(
          an_instance_of(Morandi::UnknownTypeError)
          .or(an_instance_of(Morandi::CorruptImageError))
        )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, of course. 🤦. I've no strong opinions, it was mainly that it felt like there should be a simpler way to achieve that.

@@ -73,7 +73,7 @@ def expose_from(reference_path:, tested_path:, diff_path:)
return true if @normalized_mean_error <= tolerance

metadata = RSpec.current_example.metadata
spec_name = "#{metadata[:absolute_file_path].split('/spec/').last}:#{metadata[:line_number]}"
spec_name = "#{metadata[:absolute_file_path].split('/spec/').last}:#{metadata[:scoped_id]}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a nice catch.

@knarewski knarewski requested a review from MrLukeSmith November 8, 2024 13:27
Copy link
Contributor

@MrLukeSmith MrLukeSmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've no issue with it in its current guise, it was just on the off-chance there was a simpler way to achieve the same thing. 😄

The approach you chose is still easily digestible with clear intentions. Wouldn't have approved it the first time around otherwise. 🚀

@knarewski knarewski merged commit 4e2b839 into master Nov 8, 2024
15 checks passed
@knarewski knarewski deleted the feat-prepare-code-for-a-new-image-processor branch November 8, 2024 13:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants