Gateway tests: remove logic downloading public DV files for testing

[sbesson]

Opening as a draft initially as the initial implementation will fail some integration tests and this could use feedback from the OME team.

The OMERO.py gateway tests have historically been relying on downloading public DV samples as part of the fixture set-up. Recent connections issues between OME CI and OME downloads have exposed the fragility of this requirement.

This PR proposes to update the test set-up to use fake files exclusively and remove all downloads from an external source.

Having tested it locally, most gateway tests passed except for a few specific ones which rely on the metadata fields within the sample files

FAILED test/integration/gatewaytest/test_image.py::TestImage::testProperties - assert None is not None
FAILED test/integration/gatewaytest/test_image.py::TestImage::testPixelSizeUnits - assert None == 0.10639449954032898
FAILED test/integration/gatewaytest/test_image.py::TestImage::testUnitsGetValue - AttributeError: 'NoneType' object has no attribute 'getValue'
FAILED test/integration/gatewaytest/test_image.py::TestImage::testChannelWavelengthUnits - assert None == 360.0
FAILED test/integration/gatewaytest/test_pixels.py::TestPixels::testPlaneInfo - assert 0 == ((35 * 2) * 1)
FAILED test/integration/gatewaytest/test_rdefs.py::TestRDefs::testEmissionWave - assert None == 457

• the pixel size tests should easy to fix by specifying the correct key value pairs test image format
• similarly, it should be possible to populate Plane elements using the PositionX metadata of similar
  On the other hand, there is no provisioning for storing the channel wavelength.

[will-moore]

Sounds like a good idea. Could we bundle a tiny text ome.xml image into the repo to test Channel wavelengths? Or maybe just skip it if no other option?

[jburel]

https://merge-ci.openmicroscopy.org/jenkins/job/OMERO-test-integration/297 3 failures this morning

[sbesson]

In addition to the 2 tests I reported initially which I was expecting to fail after my last changes, OmeroPy.test.integration.gatewaytest.test_wrapper.TestWrapper.testAllObjectsWrapped is also attempting to retrieve metadata (an instrument) which does not exist in these fake files.

I could use some guidance on how you want to proceed with next steps. Translating the DV into OME-XML as suggested in #443 (comment) is an interesting idea as it would preserve the metadata. I had initially tried this route but realised these OME-XML files must be packaged as part of omero-py. Is this something you would consider and if so, should these be addedunder omero/gateway/scripts or elsewhere?

[jburel]

Adding a test resources similar to the one in omero-common could be an option but that means that we will have 2 packages providing test files. In terms of maintenance this is not ideal
How much work will it be to expand fake reader?

[jburel]

Excluding this PR until a solution is implemented
--exclude

[sbesson]

Fine to exclude for now.

How much work will it be to expand fake reader?

Extending fake reader is doable but it would be good to define exactly what needs to happen before committing to any work. One quick thought is that the reader could make additional use of the XMLMockObjects API to create richer OME-XML metadata. XMLMockObjects.createInstrument() and XMLMockObjects.createChannel() would likely populate all the elements required for the last 3 failing integration tests but some of their assumptions might be incompatible with other options passed to the reader. Let's discuss on Monday at the Formats meeting

[jburel]

This is in the same spirit that what has been done in https://github.com/ome/openmicroscopy/blob/develop/components/tools/OmeroJava/test/integration/ModelMockFactory.java
Another could be to handle an "xml" key in the name of the fake file
i.e. testimg&xml=BlobOfOMEXML.fake
This could eventually replace the various existing conditions but that will be a broken change and probably not worth the effort