Here is another idea, though the hash looks to me to be the simplest solution:

Make the created square images small (say 10x10). Then it is practical to hardcode the expected pixel values and compare them (edit: compare pixel-by-pixel, not their hash) to the created square image's. Producing square images of size as small as 2x2, 3x3 (edit: the smaller the square image size the largest the probability they occur multiple times within the mother image, see the RGB gradient as a solution to this) is enough for testing your module, For testing behaviour at the borders just push the square image's coordinates a pixel short of the borders.There are modules to get you the raw pixel values, you probably know that but I can't inspect your module.

In order to avoid bundling testing images with your module, you can create on the fly images entirely in-memory from a random array, crop and check the pixel values against the segment in the array of pixels you started with. Being lazy, I would create the big image, crop it to a square, then stitch as many of the squares to make another big image and compare the two big images pixel-by-pixel in a simple for-loop, thus, avoiding the mental torture of indexing an array of pixels to the corresponding square image's crop coordinares.

In order to save resources for the testers and installers, create a mother image on-the-fly with incrementing pixel values (an RGB gradient). Then, to check the integrity of any square image, it is enough to check the pixel values of its four corners and verify arithmetically that they are indeed the correct ones. No bandwidth spend on transfering bundled test images, no disk-space for storing test images, no memory for storing and manipulating pixel values, no cpu for hashing them.

And a word of caution, if you do bundle test images in your module make sure you remove all metadata with, say, exiftool. And that is good practice for all images in a website.

bw, bliako