Repository navigation
Fix UctNode and MoveMaker Tests - #37
Conversation
|
Hi, @barrybecker4 could you please review this Pull Request? I found the tests mentioned in this PR are flaky and I found a way to fix them. Please let me know if you need additional details. Thanks in advance! |
The Java tests were ported to Scala, so drop those files and assert map equality instead of HashMap.toString(), which does not have a stable order. Co-authored-by: Cursor <cursoragent@cursor.com>
|
Merged current master and reapplied the fix on the Scala tests. The Java files this branch edited were removed in the Java-to-Scala port, which was the conflict.
|
|
@Rette66 - Thank you very much for your contribution. I'm sorry that it took me 3 years to notice it! I recently ported this repo from java to scala and have been making some other fixers. |
Description
Fixed the flaky test
testConstructionOfNodeWithNoChildreninside theUctNodeTestclass.Fixed the flaky test
testCrazyP1CombotestFinalPlayer1MoveInHomeBintestFinalPlayer1MoveOnPlayersSidetestFinalPlayer2MoveInHomeBintestFinalPlayer2MoveOnPlayersSidetestPlayer1CapturingMovetestPlayer2CapturingMoveinside theMoveMakerTestclass.Root Cause
UctNodeTest
The test
testConstructionOfNodeWithNoChildrenhas been reported as flaky when run with the NonDex tool. The test failed because it tries to compare two strings, but the methoductNode.getAttributes()returns a NodeAttribute Object.bb4-games/test/com/barrybecker4/game/twoplayer/common/search/strategy/UctNodeTest.java
Line 48 in 5dfcc6b
bb4-games/source/com/barrybecker4/game/twoplayer/common/search/strategy/UctNode.java
Lines 190 to 196 in 5dfcc6b
However, the
NodeAttributeclass extends from Java Hashmap.bb4-games/source/com/barrybecker4/game/twoplayer/common/search/tree/NodeAttributes.java
Line 21 in 5dfcc6b
Java Hashmap does not guarantee the order of elements in it. Therefore, it fails when applying
toString()and is compared with a hardcoded string.MoveMakerTest
All tests I mentioned at the beginning has been reported as flaky when run with the NonDex tool. These tests failed because they tried to compare two strings. They all have the same root cause, so I will use
testFinalPlayer1MoveInHomeBinfor instance.bb4-games/test/com/barrybecker4/game/twoplayer/mancala/move/MoveMakerTest.java
Lines 170 to 173 in 5dfcc6b
bb4-games/source/com/barrybecker4/game/twoplayer/mancala/move/MancalaMove.java
Lines 72 to 74 in 5dfcc6b
bb4-games/source/com/barrybecker4/game/twoplayer/mancala/move/MancalaMove.java
Line 33 in 5dfcc6b
Method
move.getCaptures()will return a Capture Object as inferred by the codes above. However, Capture Object is a Class that extends from Java HashMap.bb4-games/source/com/barrybecker4/game/twoplayer/mancala/move/Captures.java
Line 11 in 5dfcc6b
Java Hashmap does not guarantee the order of elements in it. Therefore, the test fails when applying
toString()to a Capture object and compares it with a hardcoded string.Fix
UctNodeTest
Test in this class is fixed by adding a temporary NodeAttribute
tempAttrand putting information in the hard-coded string into thistempAttr. Then comparetempAttrwithuctNode.getAttributes(). Since these two are all NodeAttribute types,assertEqualscan apply to them.MoveMakerTest
Tests in this class are fixed by adding a temporary Capture
tempCapand putting information in the hard-coded string into thistempCap. Then comparetempCapwithmove.getCaptures(). Since these two are all Capture types,assertEqualscan apply to them.How has this been tested?
Command used -
for UctNodetTest class
Command used -
for MoveMakerTest class
Note: replace Specific_Test_Name_Here with the test names mentioned in the beginning.
Command used -
for UctNodetTest class
Command used -
for UctNodetTest class
Note: replace Specific_Test_Name_Here with the test names mentioned in the beginning.
Replace X with an int number.
The NonDex test passed after the fix.