Return to Answer

I think you should have a Game class, which you would call like so:

Game(number_of_games=10)

The Game instance would then keep track of the games by itself. You would create reports in Game.__init__.

Game would then call GameEngine which would handle only one game and would be run like so:

# somewhere in `Game`
result = GameEngine().run()
self.report(result)

I think all the report stuff should go in the Game class itself as methods. If I am not clear enough, maybe I should draw you a picture...

├── Game
│ │ with attributes to keep track of the score
│ ├── __init__(number_of_games)
│ ├── nextgame()
│ └── report(result)
│
└── GameEngine
 │ with attributes to keep track of the board
 ├── __init__()
 └── ... the game engine ...

I think you should have a Game class, which the user would call like so:

Game(number_of_games=10)

The Game instance would then keep track of the games by itself.

Game would then call GameEngine which would handle only one game and would be run like so:

# somewhere in `Game`
result = GameEngine().run()
self.report(result)

I think all the report stuff should go in the Game class itself as methods. If I am not clear enough, maybe I should draw you a picture...

├── Game
│ │ with attributes to keep track of the score
│ ├── __init__(number_of_games)
│ ├── nextgame()
│ └── report(result)
│
└── GameEngine
 │ with attributes to keep track of the board
 ├── __init__()
 └── ... the game engine ...

Game would be kind of the "meta" version of GameEngine if you think of it like that. The user won't be exposed to the internals of the game but only to the "launcher".

What is the separation of concerns. Well Game doesn't care about the board.

And GameEngine doesn't care about the user, and the score.

You can test the GameEngine easily because it only includes the core stuff.

You can test Game easily by using Mocking. How can I do "mocking" ? Simple add this before doing unittesting:

class GameEngine:
 def run(): return 'Tie'

See unittest.mock for more info.