Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Checkmate Tests #67
I've added more tests for checkmate, which were taken from classic checkmate patterns. Unfortunately, that revealed some flaws in our checkmate method.
Checkmate essentially involves 3 checks:
In our case, it also involves checking the state of the game. For example, if you check if any of your pieces can capture the attacker, one needs to keep in mind that there be something like a dovetail check, where if the first piece is captured, the second piece already has your King in check (and therefore, you're in checkmate).
Using any of these three checks individually without also checking the state of the game after the move has been carried out will give false results.
After looking at our options, I do believe that using something like a Transaction is still our best bet, since it will capture the state of the game after the move has been carried out. I've refactored that method, but you'll see that it still doesn't pass all of the tests. I've also written 2 of the 3 checks independently, but they suffer from the state problem that I mentioned.
Any ideas would be great!
I got it working! I think that the code needs to be refactored, as checkmate is pretty complex, but it passes the tests!
What I noticed when I was running my tests manually in Rails console was that the pieces were not rolling back to their original positions when the transaction ended. Solution? I store their positions prior to the transaction and then make sure to update attributes after the transaction to keep them where they should be. This solves the problem of the transaction seemingly checking invalid moves (they weren't invalid -- the piece had just moved).
Any comments about how to best refactor, or any suggestions for more tests would be appreciated.
I just refactored a whole lot of stuff and committed it to this branch. Here are a few highlights: