How to test functionality that requires a certain internal state?

Question

I'm struggling to test functionality in a class where the class has to be in a certain state for the functionality to work, but the class cannot be put directly into a given state by design, to maintain state integrity.

I'm developing the back end of a board game in Kotlin. It includes a Game class that is responsible for (1) processing game commands from the player's front-end, and (2) providing information back to the front-end about the game state. I'm trying to write tests for this class, but I can't seem to find a reasonable balance between encapsulation and testing.

The interface visible to the unit tester looks like this:

class Game(numPlayers: Int = SETTINGS_DEFAULT_NUM_PLAYERS) {
    
    fun processCommand(command: Command): String { ... }

    fun getPlayerVictoryPoints(playerIndex: Int): Int { ... }
    fun getAvailableActions(): List<GameAction> { ... }
    fun getPurchasedCards(playerIndex: Int): List<Card> { ... }
    fun gameIsOver(): Boolean { ... }
    .
    .
    .

}

processCommand() is the only method that can affect the state, other than the constructor itself. All other visible class methods return some information about the game state.

The Command object contains a command based on user input, such as "take red currency", "purchase card number 4", "convert blue currency to yellow", and so on. The processCommand() method gets these commands processed.

At the start of the game, players have no currency and no cards purchased. Small randomly selected and rotating assortments of cards and currency are also exposed. Players have to gather the currency and purchase cards from what is exposed. These cards give players special abilities, like converting currency from one type to another, or granting victory points upon performing specific game actions such as purchasing a card. The game ends when any player has purchased more than a certain number of cards.

To test processCommand() with a Command that converts currency types, for instance, the player has to have purchased a card that allows such a conversion. The case is similar with several other Commands. For a method like getPlayerVictoryPoints(), a player needs to have already purchased a card that grants victory points, and then be able to perform the specific action that triggers the victory points. Testing whether the gameIsOver() method ever returns true requires a complete game to be played out.

As processCommand() is the only method that takes any input, and it's impossible to predict what currency and cards are available, I believe the core functionality of my game is currently impossible to test.

Here's some options that are on the table, in no particular order:

1. add internal (module-visibile) methods to Game class that expose implementation details
2. increase visibility on existing private and protected methods and properties to internal
3. refactor Game to an open class, with visibility on all its private methods and properties widened to protected (visible to subclasses), and create a TestingGame subclass of Game with extra methods that make setting state simple

I believe all of those violate encapsulation principles because a third-party front end would have access to the implementation details and be able to set invalid states.

I've had this problem before with similar game projects, so I'm looking for explanations of broader methods and principles that address this problem, and perhaps how they apply to this code as a bonus.

I've read up on mocking, but since this isn't an issue with an outside dependency, I don't think it applies here. Also, I understand what TDD is and how it may have helped me if I'd started out with that, but I'm fairly certain I would have arrived at this same question, just during the design phase rather than while coding.

Answer 1

Tests should run fast.

Now sure, you could set up each test by using processCommand to process every commend needed to get the game into the state you want to test but that's pitifully slow.

The alternative is to load in game state from some kind of cache or serialization. Heck even calling a constructor could do this. Yeah, that exposes state.

But come on. It's only exposed to the tests that use it. And it's hidden as soon as it's constructed. So this knowledge isn't going to spread to the rest of the project. It's not like you have getters right?

Yes, you could use some mocking voodoo or reflection magic to set internal state but a simple constructor can keep your secrets without being all weird. And it's fast, so your tests will be fast. Which means you'll actually run them often enough for them to do some good.