Write test cases for game loop

[nashirj]

Should have test cases that allow verifying all functionality in game loop. These test cases can be extended to serve as test cases for the physical hardware once we have the hardware in place. Examples of things to validate:

• Normal moves
• Promotion
• Captures
• Moving to/from graveyard

This issue should be kept up to date and remain open until all existing functionality of the game loop has test cases. Then all future game loop stuff should include test cases to validate the new functionality.

[nashirj]

As part of this issue, should set up a "debug" mode of interaction.

This would run through a specified test game and send moves to board exclusively through CLI. This would let us validate

1. all game loop side code
2. hardware/arduino code
3. computer vision since we will have perfect knowledge of board state and can test how CV works with real board moves

[nashirj]

When debug mode of interaction can be specified with an optional --debug flag; if debug, we'll loop through the main game loop and only accept debug style messages from the human user (properly formatted moves that will be sent directly to Arduino; this will allow us to send the HOME_AXIS command). otherwise, we'll use the same logic currently in place. functionally, everything else should stay the same.

We can also have a --test flag that reads a file and sends commands from the file to the board. Prereq: need the board set up properly before the test case runs. Can optionally have a --all flag that runs all tests.

It might end up being cleaner to create a new boardtest.py and boarddebug.py file, but I think there would be a lot of duplication.

[LSaber36]

Hardware tests:

• Be able to test aligning any axis to either minimum or maximum positions
• Be able to make specific moves
• Turning on/off electromagnet

[LSaber36]

I was thinking about it, and I think that there needs to be a hardware option for both --debug and --test flags. Perhaps we could add another flag to decide between hardware and software options, maybe --hardware (since it would probably be software by default). This extra --hardware flag would simply control where the test cases, or cli input, would be sent (Either to the chess engine or to the arduino).

I think we should do it this way because the behavior for running cases for either scenario are different. The software version is based on cases that get processed by the engine and everything, whereas the hardware version is based on directly sending commands to the arduino, bypassing the chess engine.

[nashirj]

The Arduino tests should validate that if the end stops are hit, the movement stops.