How can we test a section of a game?

Question

I'm making a clone of an old atari 2600 game, so it's simple, only slightly more complex than the original.

I'm realizing that even the simplest of games have different "parts", what is a good design method to be able to test those sections without having to "play through" to that part?

Specifically, (it's a "breakout" clone) if I'm modifying and testing code that runs when the game is beaten, I don't want to have to play through the whole game just to see if my code works. I can only imagine how complicated this kind of testing is for a game of substantial size.

How do real devs make their game such that they can test just a certain section, or test a section under certain possible in-game circumstances without having to play through to that part?

Answer 1

They have console commands.

There is a reason skyrim has all the commands in it. That game was very extensibly tested. And because it has couple hundred hours of content with every cave and guild, and some of this content is bound to a level, there is no way to make everyone play through everything.

Do the same, create some commands whivh put you on an entered level, one which destroys every block, etc.

You of course don't need to keep it in the game when you release it. Some games do that to make players be able to ppay around with the game a bit more.

Answer 2

A bad development team would hire a bunch of QA staff (testers) to play the game over and over again, reporting bugs into an ever vacuous database. Even with the aid of console commands this is an expensive and slow process, and not what you should be using a QA team for. The testers should be exploring edge cases and pushing the game to its logical limits, not validating your own wobbly code you couldn't be bothered to test.

A studio with solid development practices will write automated tests that run every time they check in new code. This allows certainty that new changes don't break previous functionality. With projects as vast as the ones you find in game development this is the only way to confidently deliver a functioning product. Not following these practices is what leads to crunch, and crunch kills good developers. In today's modern age of games like Overwatch or Dota 2 that have to be maintained and altered consistently after release it's the only way to iterate a product sustainably.

The answer is to automate as much testing as you can. In your case write a helper method that destroys all the blocks and then engineer a test that executes this and validates the win conditions are being satisfied. If this is difficult to test in your environment then it's potentially a sign your current code is too coupled and could do with some abstracting.