How to unit-test a reducer with guaranteed randomness? (Redux)

Question

I'm attempting to create a react/redux app that isn't the standard "todo". So I went with 2048, it's a fairly fun game that I could fiddle around with.

I've got the game "working" (the game plays by the rules), and now I'd like to retro-actively add some test cases to ensure I don't break anything important down the line (and, y'know, practice).

I have a reducer set up for the board that listens for varying actions:

const Board = (state = 0, action) => {
    if(state === 0){
        return createBoard();
    }
    switch (action.type) {
        case 'MOVE_UP':
            return move(state, 0);
        case 'MOVE_RIGHT':
            return move(state, 1);
        case 'MOVE_DOWN':
            return move(state, 2);
        case 'MOVE_LEFT':
            return move(state, 3);
        case 'NEW_GAME':
            return createBoard();
        default:
            return state;
    }
}

However the move(board, direction) function does most of the heavy lifting and is where the problem arises:

function move(board, direction){
    //0: up, 1: right, 2: down, 3: left
    var b;
    switch(direction){
        case 0:
            b = mergeBoardUp(board);
            break;
        case 1:
            b = mergeBoardRight(board);
            break;
        case 2:
            b = mergeBoardDown(board);
            break;
        case 3:
            b = mergeBoardLeft(board);
            break;
        default:
            b = board.map(x => x);
    }
    if(distinctBoard(board, b)){
        b = addNewTile(b);
    }
    return b;
}

My understanding is that reducers should be black-box tested (don't try to pull out and test the "mergeBoardUp" function, test the state after using it). Due to the nature of the game, a new tile is added whenever a valid move is played (if(distinctBoard){addNewTile}). I've got a pretty good set of test cases I'd like to implement in terms of testing board rotations and merges, however I can't figure out a way to work around the "random" tile placement.

example test case for reference:

it("MoveUp - simple", () => {
    var input = [[2,0,0,0],
                [2,4,8,16],
                [2,4,0,16],
                [2,4,8,0]];

    var inputHistory = {
        past: [],
        present: input,
        future: []
    };

    var expected = [[4,8,16,32],
                    [4,4,0,0],
                    [0,0,0,0],
                    [0,0,0,0]];

    var rotatedLeft = Board(inputHistory, MovementButtons.moveUp()).present;

    expect(rotatedLeft).toBe(expected);
})

The above fails, because after the valid move, a new tile is placed randomly in the array, causing the "expected" array to always be off by one value.

What would be the appropriate approach for testing in this scenario? My instincts are yelling at me to separate the functions I would like to test into a utility file (and test the exported functions from that), but that appears to be an anti-pattern for testing reducers.

Answer 1

The real issue here is that randomness shouldn't be happening in the reducer. Reducers are supposed to be "pure functions", with no side effects. Reducer code that isn't pure will still run, but time-travel debugging will not work as intended, and as you've found, testing becomes difficult.

There's a couple ways you could consider restructuring things. You could put the bulk of the logic into the action creator, and have the reducer logic simply merge data into place as needed. Another approach might be to have the action creator generate whatever randomness is needed, and include that in the action. That way the reducer itself stays pure, deterministic, and testable.

Answer 2

I would re-ask, What am I trying to test? It looks like you could be testing two different functionalities: MoveUp's merge and MoveUp's random new row.

It seems like you could properly unit test the MoveUp's merge functionality simply with:

    expect(rotatedLeft.slice(0,3)).toEqual(expected.slice(0,3));

By properly capturing the merge of the top three rows, I'd say this suffices as a unit test for MoveUp's merge functionality.

Then separately, you could test that the last row is random by checking that each value in the last row belongs to the set of possible random values.

    for (var i = 0; i < rotatedLeft[3].length; i += 1) {
        expect([0, 2, 4]).toContain(rotatedLeft[3][i]);
    }