The problem here is that the methods that this objects return is hard/impossible to replicate by hardcoding because it includes images and arrays with several parameters. This complicated data is used by the other object to perform some calculations, and this method is suposed to format the output and make some graphical analysis with the output data.
This sounds like a lot of work/responsibility for something that you call a "unit". For example, it makes no sense for both image processing and graph outputting to be tested as a single unit. Those are two completely independent behaviors.
I support RobertHarvey and Kain's suggestion of breaking this down in smaller chunks. It's going to dramatically improve your testability and reduce the complexity of your inputs and outputs.
Unit testing with large input data
Let's assume you've broken down your logic, and you're trying to unit test the image processing logic. For the sake of example, let's say the logic counts how many pixels of each color there are in the image.
This is an appropriate unit test, but the image is still a non-trivial data set to construct out of nowhere. So how do you define this test data?
The problem here is that the methods that this objects return is hard/impossible to replicate by hardcoding because it includes images and arrays with several parameters.
Unit tests don't limit you to having to hardcode inputs in the test method itself. What is important is that the values of the input data are considered a fixed given, i.e. the test presumes a specific input. For simple data, that's trivially done by hardcoding it, but that's not feasible for larger data sets.
looking for a way of testing this method which doesn't include to construct the two objects needed inside the test
The simple solution here is to include an actual image in your test project, and simply read that image's file content. If I know that
myImage.jpg contains 110 black pixels and 890 white pixels, I can write a unit test that asserts these values are the output of the image processing logic.
Just like how you decide an arbitrary value when hardcoding something, you can use an arbitrarily decided image file.
It doesn't have to be a literal image file. It could also be a hardcoded string that you keep in a separate file, e.g. a
TestImages class with static string properties containing the base64 file content.
I would try to work with image files where possible, simply because it's easier for a test writer to understand which image they're using in their test. The minor performance hit from reading the file is negligible since unit tests aren't written to be performant to begin with.
Note: The same answer/principle applies to any unwieldy large data sets, not just images. Simply define them elsewhere and refer to them in your unit test. For example, in a unit test for an import script that had to process a massive XML file, we simply had a collection of XML files with particular representative data cases which we used.