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

Use ImageAssert comparison, as MetadataExtentApiTests checksums differ based on font engine #5302

Merged
merged 3 commits into from Jan 8, 2021

Conversation

jodygarnett
Copy link
Contributor

@jodygarnett jodygarnett commented Jan 4, 2021

This has been an outstanding issue for some months, ignoring these checks allows remaining tests to run. This commit has been isolated from #5260 as per @cmangeat request.

To quickly verify this change:

cd services
mvn test -Dtest=MetadataExtentApiTest

I guessed at a tolerance, would love confirmation on:

  • macOS OpenJDK and OracleJDK
  • linux
  • windows

image comparison

I am going to take a moment to see if I can do an image compare and have a stable build across platforms.

To run test with interactive review of failures:

mvn clean install -DMetadataExtentApiTest.save.png=true -Dorg.geotools.image.test.interactive=true -Dtest=MetadataExtentApiTest -Djava.awt.headless=false
  1. When running without a reference file, there is an option to save a new reference file:

image

  1. Images that are within the provided tolerance are accepted

  2. Images outside the provided tolerance are rejected

  3. When running with -Dorg.geotools.image.test.interactive=true any failures can be visually inspected, with an option to update the reference image.

image

This has been an outstanding issue for some months...
This check allows remaining tests to run.
This allows the use of a tollarance to account for font differences between platforms.
@jodygarnett
Copy link
Contributor Author

jodygarnett commented Jan 5, 2021

Travis failed to download a jar (unrelated to this PR?):

/home/travis/.m2/repository/org/geotools/gt-coverage/23.0/gt-coverage-23.0.jar; error in opening zip file

This file is available so travis is just having trouble.

⚠️ Note travis is shutting down shortly, any plans to migrate to github?

@jodygarnett jodygarnett changed the title Ignore MetadataExtentApiTests on macOS as file checksums differ Use ImageAssert comparison, as MetadataExtentApiTests checksums differ based on font engine Jan 5, 2021
assertImage(
REFERENCE+"lastModifiedModified.png",
reponseBuffer,
37);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@josegar74 this is an example of a tolerance that I guessed at to account for platform differences.

If you want you can reduce this to zero and we can get an actual difference between linux and macOS.

}

@Test
public void lastModifiedNotModified() throws Exception {
final boolean OS_NAME_MAC_OS = System.getProperty("os.name").toLowerCase().startsWith("mac os");
if( OS_NAME_MAC_OS ) return; // skip on macOS
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test is being skipped still as it does not work for me on macOS.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@josegar74 reported this test failing on linux:

[ERROR] org.fao.geonet.api.records.extent.MetadataExtentApiTest.lastModifiedModified  Time elapsed: 12.078 s  <<< FAILURE!
java.lang.AssertionError: Range for response status value 304 expected:<SUCCESSFUL> but was:<REDIRECTION>
    at org.fao.geonet.api.records.extent.MetadataExtentApiTest.lastModifiedModified(MetadataExtentApiTest.java:166)

Since it is returning a result I thought I would collect the image, and keep the test enabled:

image

These tests are producing different results across platforms resulting in developers skipping tests
@jodygarnett
Copy link
Contributor Author

Revised threshold based on ubuntu results:

[ERROR]   MetadataExtentApiTest.getOneRecordExtentAsImage:135->assertImage:414 Images are visibly different, found 521 different pixels, against a threshold of 37

I would still love a visual from this environment to see if is just font differences, or if the "no protocol setting" text is specific to macOS.

@cmangeat
Copy link
Collaborator

cmangeat commented Jan 6, 2021

Revised threshold based on ubuntu results:

[ERROR]   MetadataExtentApiTest.getOneRecordExtentAsImage:135->assertImage:414 Images are visibly different, found 521 different pixels, against a threshold of 37

I would still love a visual from this environment to see if is just font differences, or if the "no protocol setting" text is specific to macOS.

(What do you use as jdk with osx ? If oracle, is it possible to test with openjdk ?)

@jodygarnett
Copy link
Contributor Author

(What do you use as jdk with osx ? If oracle, is it possible to test with openjdk ?)

See description at the top of the PR, I tested with oracle and openjdk.

}

@Test
@Ignore
Copy link
Collaborator

@cmangeat cmangeat Jan 6, 2021

Choose a reason for hiding this comment

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

cf.

last modification date is "2015, Calendar.OCTOBER, 21, 07, 28, 0"

version available at browser side date is "Wed, 21 Oct 2015 07:29:00 UTC"

response should be "not modified" ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If the test is showing a new bug it can be addressed in a separate PR. I do wonder if the failure in this case is timezone sensitive ...

Copy link
Collaborator

Choose a reason for hiding this comment

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

If service return "not modified" it is not a bug. Otherwise, the test should be deleted.

}

@Test
@Ignore
Copy link
Collaborator

Choose a reason for hiding this comment

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

In fact, as test purpose is about checking for "If-Modified-Since" and cache management, checking that returned image fits is not really important, but it anyway should ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was testing the returned image before using a checksum ... if the image is not of interest we can remove the check :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't know why the test is failing with mac os. Checking that image retrieved from cache is the good one can make sense. Otherwise the test should be removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it is failing based on timezone, not macOS.

@cmangeat
Copy link
Collaborator

cmangeat commented Jan 6, 2021

Great, proud to know there is an image compare somewhere !

@jodygarnett
Copy link
Contributor Author

@juanluisrp was able to visually confirm the results, so I think this is good to go.

@juanluisrp
Copy link
Contributor

linux.zip
Images generated using Lubuntu 20.04.1 with openjdk 8. I can't find any appreciable diff.

@josegar74 josegar74 merged commit f33c500 into geonetwork:master Jan 8, 2021
@jodygarnett
Copy link
Contributor Author

jodygarnett commented Jan 11, 2021

linux.zip
Images generated using Lubuntu 20.04.1 with openjdk 8. I can't find any appreciable diff.

Thanks @juanluisrp - your download totally confirmed my suspicion: the text in the images show a difference between "expected" and "actual" in each case. The text shows up as white, so you need to show this against a dark background to see the difference!

Expected (from macOS):

image

Actual (in this case from linux):

image

This can be alleviated by including a specific font in the geonetwork war and making use of it when drawing error messages such as this on the returned image.

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.

None yet

4 participants