Implementing the New FSM Transition Design with Regression Testing

TLDR

Continuing to implement the new Transition / Finite State Machine design. Regression testing by manually running scripts and verifying board state.

Test coverage baseline - redesign allows for much easier testing and less code duplication / misdirection.

Logic from Glides being moved into updated Transitions.

public class TransitionRollForOrderRollPlaceFreeSettlement extends TransitionBase {

  public TransitionRollForOrderRollPlaceFreeSettlement() {
    super(StateEnum.ROLL_FOR_ORDER, ActionEnum.ROLL, StateEnum.PLACE_FREE_SETTLEMENT);
  }

  @Override
  boolean canUpdateState(CatanGame catanGame, Map<String, String> parameters) {
    return catanGame.getStateEnum() == getStartStateEnum()
        && catanGame.getPlayers()
        .stream()
        .filter(p -> p.getTurnOrderRollResult() != null)
        .count() == catanGame.getPlayers().size() - 1;
  }

  .
  .
  .

}

Main work

• Translate existing Transitions / States / Glides into newly designed Transition object.
• Introducing ActionEnum.NOOP to replace “Free Transitions.”
• Regression testing the application by manual verifying the game state after testing scripts are run.
• Fixing a regression that was introduced that broke the transition from LOBBY state to ROLL_FOR_ORDER state.

Challenges

• We have situations where we could either:
  1. Define a Transition from A -> B via Action X
  2. Or we could define one Transition from A -> A via Action X and another Transition from A -> B via Action NOOP.
• It’s unclear if either approach is best in all cases. It is likely dependent on the business logic being implemented.
  • For example, we can make the logic for joining the game lobby very simple if we define a NOOP / “free transition” out of the JOIN_LOBBY state that simply checks for the max number of players.
• Now have lots of unit test coverage to actually add / implement. :)

Learnings

• Beginning to research and brainstorm how to design controller and integration tests. My automated scripts (that have been invaluable for manual regression testing) could then be integrated into the repo’s test suite.
  • Could also explore pre-commit hooks that would enforce that these test suites (unit and integration) are still passing.
• Researching general Exception design considerations before writing controller tests.
  • Main question: What kind of information / JSON object should the frontend see if there is a genuine server failure vs an illegal Catan move?