https://github.com/raphw/byte-buddy,505b9bb02920c6f5d8662ce310f9568acd1e5baf,byte-buddy-dep,net.bytebuddy.dynamic.scaffold.MethodGraphCompilerDefaultTest.testGenericNonOverriddenInterfaceImplementation,ID

[Lord-Mendoza]

The following test case started becoming flaky during the following commit:
raphw/byte-buddy@74e1f7a

The relevant code changes are displayed here:

What went wrong:

• The issue actually involves two commits. We’ll refer to the previously compilable, passing commit as Commit 0, non-compilable commit as Commit 1, and compilable commit, but flaky as Commit 2.
• In Commit 1 the author introduced a new net.bytebuddy.test.utility.FieldByFieldComparison.java utility file and replaced the usage of org.hamcrest.CoreMatchers/is() method with FieldByFieldComparison.java/hasPrototype().
• In Commit 2 the author also added the usage of TypeDescription.ForLoadedType.of(). Note that Commit 2 only fixed compilation issue and revealed that the test itself is flaky.
• Commit 1 was what caused the test to now be flaky in comparison to Commit 0.
  1. In the test method it uses org.hamcrest.MatcherAssert.assertThat which takes a Matcher class as its second parameter.
  2. Since the matcher class was switched from the original org.hamcrest.CoreMatchers/is() to now the net.bytebuddy.test.utility.FieldByFieldComparison.java there are some intermittent incompatibility when performing the assertThat call (which again comes from org.hamcrest package).
  3. As you can see in the test error below, the test should have passed since they both yield the same net.bytebuddy…@cade6414 as the expected and actual.

4. The Matcher class itself (which is the net.bytebuddy.test.utility.FieldByFieldComparison.java) started causing issues. Reverting back to the original usage of org.hamcrest.CoreMatchers/is() fixes the flakiness of this issue.
   

The following log shows the test case where it became flaky (After Commit 1 and Commit 2):
Assignment4-Mendoza_PartTwo_FlakyTestCommit.log

With the solution I suggested being implemented, and running the NonDex tool against it, it shows the flakiness being resolved:
Assignment4-Mendoza_PartTwo_NonFlaky-And-Passing-TestCommit.log