Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 877513 - dev-java/assertj-core-3.10.0 fails tests
Summary: dev-java/assertj-core-3.10.0 fails tests
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Java team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-18 00:15 UTC by Jonathan Lovelace
Modified: 2022-10-20 18:07 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
dev-java:assertj-core-3.10.0:20221017-231429.log (dev-java:assertj-core-3.10.0:20221017-231429.log,441.98 KB, text/plain)
2022-10-18 00:15 UTC, Jonathan Lovelace
Details
emerge-info.txt (emerge-info.txt,7.98 KB, text/plain)
2022-10-18 00:15 UTC, Jonathan Lovelace
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Lovelace 2022-10-18 00:15:02 UTC
Created attachment 824641 [details]
dev-java:assertj-core-3.10.0:20221017-231429.log

=dev-java/assertj-core-3.10.0 fails its test phase on one of my two machines, after passing on the other machine five days ago.

The specific tests that failed were as follows (extracted from the build log):
1) extracting_by_single_extractor_should_keep_assertion_state(org.assertj.core.api.list.ListAssert_assertionState_propagation_with_extracting_Test)
2) extracting_by_several_functions_should_keep_assertion_state(org.assertj.core.api.list.ListAssert_assertionState_propagation_with_extracting_Test)
3) extracting_by_throwing_extractor_should_keep_assertion_state(org.assertj.core.api.list.ListAssert_assertionState_propagation_with_extracting_Test)
4) extracting_by_strongly_typed_name_should_keep_assertion_state(org.assertj.core.api.list.ListAssert_assertionState_propagation_with_extracting_Test)
5) extracting_by_name_should_keep_assertion_state(org.assertj.core.api.list.ListAssert_assertionState_propagation_with_extracting_Test)
6) extracting_by_multiple_names_should_keep_assertion_state(org.assertj.core.api.list.ListAssert_assertionState_propagation_with_extracting_Test)

And for each of these the abbreviated stack trace looks the same:
org.assertj.core.util.introspection.IntrospectionError: 
Can't find any field or property with name 'comparatorsByType'.
Error when introspecting properties was :
- No public getter for property 'comparatorsByType' in org.assertj.core.api.ListAssert 
Error when introspecting fields was :
- Unable to obtain the value of the field <'comparatorsByType'> from <org.assertj.core.api.ListAssert@1>, check that field is public.
	at org.assertj.core.util.introspection.PropertyOrFieldSupport.getSimpleValue(PropertyOrFieldSupport.java:77)
	at org.assertj.core.util.introspection.PropertyOrFieldSupport.getValueOf(PropertyOrFieldSupport.java:57)
	at org.assertj.core.api.GroupAssertTestHelper.comparatorsByTypeOf(GroupAssertTestHelper.java:26)
	at org.assertj.core.api.list.ListAssert_assertionState_propagation_with_extracting_Test.extracting_by_multiple_names_should_keep_assertion_state(ListAssert_assertionState_propagation_with_extracting_Test.java:140)
	... 33 trimmed
Caused by: org.assertj.core.util.introspection.IntrospectionError: Unable to obtain the value of the field <'comparatorsByType'> from <org.assertj.core.api.ListAssert@1>, check that field is public.
	at org.assertj.core.util.introspection.FieldSupport.readSimpleField(FieldSupport.java:241)
	at org.assertj.core.util.introspection.FieldSupport.fieldValue(FieldSupport.java:198)
	at org.assertj.core.util.introspection.PropertyOrFieldSupport.getSimpleValue(PropertyOrFieldSupport.java:67)
	... 37 more
Caused by: java.lang.IllegalAccessException: can not accesscomparatorsByType because it is not public
	at org.assertj.core.util.introspection.FieldUtils.getField(FieldUtils.java:69)
	at org.assertj.core.util.introspection.FieldUtils.readField(FieldUtils.java:141)
	at org.assertj.core.util.introspection.FieldSupport.readSimpleField(FieldSupport.java:204)
	... 39 more
Comment 1 Jonathan Lovelace 2022-10-18 00:15:36 UTC
Created attachment 824643 [details]
emerge-info.txt
Comment 2 Jonathan Lovelace 2022-10-18 00:31:41 UTC
Belatedly Googling, I found https://github.com/assertj/assertj/issues/1338, which looks at first glance to be this exact issue, and claims that it's fixed by https://github.com/assertj/assertj/commit/905cfdeeb9b01f35bab76377792eaca121146835, but that commit looks (by comparing the patch to the source code unpacked in $S) to already be part of this version.
Comment 3 Volkmar W. Pogatzki 2022-10-18 07:09:11 UTC
(In reply to Jonathan Lovelace from comment #2)
> [...]

Thanks for reporting and excellent analysis.
However I cannot reproduce those errors.
Comment 4 Jonathan Lovelace 2022-10-19 00:11:35 UTC
I get them consistently on that one machine (which is a ~2010 MacBook), but my other machine passes all the tests without error (I just checked it again). If there's some way to run the tests completely serially (like MAKEOPTS=-j1), that might either work around the issue or make it reproducible, but I'm not aware of any way to do so.

I did a little more cursory searching through the upstream Git repository, and found some other commits related to making tests more robust against conflicting temporary changes to configuration, but all the ones I remember finding postdated the modularization of the code and so couldn't be easily adapted to apply to this release.
Comment 5 Volkmar W. Pogatzki 2022-10-19 19:20:32 UTC
(In reply to Jonathan Lovelace from comment #4)
> I get them consistently on that one machine (which is a ~2010 MacBook), but
> my other machine passes all the tests without error (I just checked it
> again). If there's some way to run the tests completely serially [...]

Separating tests could be done by calling 'java-pkg-simple_src_test' for each test as is done in https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-java/reload4j/reload4j-1.2.22.ebuild.