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
Conversation
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.
Travis failed to download a jar (unrelated to this PR?):
This file is available so travis is just having trouble. |
assertImage( | ||
REFERENCE+"lastModifiedModified.png", | ||
reponseBuffer, | ||
37); |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
c009a04
to
f5883c7
Compare
These tests are producing different results across platforms resulting in developers skipping tests
f5883c7
to
0eba538
Compare
Revised threshold based on ubuntu results:
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 ?) |
See description at the top of the PR, I tested with oracle and openjdk. |
} | ||
|
||
@Test | ||
@Ignore |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cf.
core-geonetwork/services/src/test/java/org/fao/geonet/api/records/extent/MetadataExtentApiTest.java
Line 371 in 0eba538
calendar.set(2015, Calendar.OCTOBER, 21, 07, 28, 0); |
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" ?
There was a problem hiding this comment.
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 ...
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Great, proud to know there is an image compare somewhere ! |
@juanluisrp was able to visually confirm the results, so I think this is good to go. |
linux.zip |
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): Actual (in this case from linux): 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. |
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:
I guessed at a tolerance, would love confirmation on:
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:
Images that are within the provided tolerance are accepted
Images outside the provided tolerance are rejected
When running with
-Dorg.geotools.image.test.interactive=true
any failures can be visually inspected, with an option to update the reference image.