Complete Nurikabe test suite #678
Conversation
Wrote a new unit test for the Nurikabe black square contradiction rule.
Added two new test cases for the Black Bottleneck direct rule. The first test case checks whether bottlenecks can be successfully detected in a corner The second test case intuitively looks like a bottleneck, but is not actually a bottleneck. This is to avoid false positives.
Added comments to the various test cases, and fixed the corner test for the black square contradiction rule.
This commit contains the remainder of the unit tests for the Nurikabe contradiction rules, with the corresponding board files and appropriate comments
This commit includes all the finished Nurikabe test cases, including direct rules and the case rule. Comments have been added where appropriate. No significant change was made in some classes.
This commit includes a complete rewite of the case rule to test that it creates the number of children required in a correct manner. It also includes minor changes to some other tests.
Made a minor addition to the case rule to make it more comprehensive - testing the equality of the non-modified cells, and the relative sizes of the all the boards.
|
@Relurk1 Make sure you resolve the merge conflicts. We'll review the pull request after that. |
There was a problem hiding this comment.
You need to add some more test cases for where a rule does not check out, i.e. some 'false' cases of a rule application, and make sure that LEGUP does indeed not let the rule check out:
Add a false Black between regions case, e.g. where on of the regions doesn't contain a number, or where it looks like you are dealing with two whites from separate regions, but they are actually part of some region, just through some long path.
Add a false Black Square contradiction test .. where there is no black square
Add a false Corner Black test ... e.g. where a cell is made black immediately diagonally from a white cell ... but where the white region that that cell belongs to can be extended in other ways other than the two squares between the white and black cell
Add a false Fill In Black ... where you only have 3 out of 4 sides of a blank square being black
Add a false Fill in White ... where there is no black cells on the other side of the white cells.
Add a false Isolated Black case ...
Multiple Numbers: do you have a case where a region has two numbers that are the same? Should still check out as a contradiction, but maybe an important edge case?
Add a false Multiple Numbers cases ... : include two regions, one with one number inside, and one with no number inside.
No Number: how about a region made up of white (no nubner) of blank(gray) cells completely enclosed by black cells?
Add a false No Number case: Maybe something where a region of all white and blanks is completely surrounded by blacks, where not all whites are connected, but where there is at least one white number cell?
Add a false Prevent Black Square case
Surround Region: Do you have a test case where you only place some of the surrounding black squares?
Add a false case: Maybe where the black surrounding squares leave some blank space between themselves and the white region?
Add a false Too Few spaces case: have a white region completely surrounded by blacks, and a white region is smaller than the number in it, but there are still sufficient blanks that can be used to get that region to that number. You can also test a white region with multiple numbers in it .. the rule should check pout if and only if at least one of the numbers in the white region cannot be satisfied. Or tru a white region with a number in it that is smaller than that region ... that is a contradiction... but not a Too Few Spaces contradiction.
Too Many Spaces: Again, test a white region with multiple numbers in it: the rule should check out if there is at least one number in the region that is smaller than the white region.
Add a false WhiteBottleNeck case
|
I can;t do the actual test ... but I read the descriptions of the tests. All rules are covered, but for almost all of them some test should be added that checks that a 'false' or mistaken application of the rule does indeed not check out (see my comments above). But if someone else can test the current tests, let's go ahead, approve, and merge, and then we can add some further tests later. And big thanks to the person writing all these tests so far! |
@jac-oblong I'll leave this to you. |
|
|
||
| Assert.assertTrue((caseBoard.getCell(0,0).getData().equals(v1) || caseBoard.getCell(0,0).equals(v2)) && | ||
| (caseBoard2.getCell(0,0).getData().equals(v1) || caseBoard2.getCell(0,0).getData().equals(v2))); | ||
| Assert.assertFalse(caseBoard.getCell(0,0).getData().equals(caseBoard2.getCell(0,0).getData())); |
There was a problem hiding this comment.
Instead of using Integer objects, use NurikabeCell.getType(). This will return a NurikabeType that you can do the equality checks with. It will make the code more readable.
|
@Relurk1 There is one comment I made on the BlackOrWhiteCaseRuleTest (readability change, not a fault in the logic). Once you finish that, everything should be good. |
This commit includes: - A change for readability made in the case rule, replacing Integer objects with NurikabeType - Adding false test cases where necessary - Updating test cases where necessary
Description
This pull request contains the new test suite for Nurikabe. This includes tests that have been unchanged, tests with some additions, and tests that are entirely new. Each test has a corresponding board file.
Type of change
How Has This Been Tested?
Every new/rewritten test was run with the relevant rules. I made sure that every test passes when it should. When tests failed, I confirmed that the rules they were checking were correct, and then rewrote the tests more accurately. No incorrect rules were found in the process of creating this test suite.
Checklist: