Summary

You covered a lot of classes in this chapter, which will be useful in your later projects. Unit testing is also an important point and I hope I convinced you that writing unit tests first is the way to go. The Breakout game got a little attention at the end of the chapter. The chapter is long enough as it is and luckily you could skip a few points of the Breakout game because many parts of the game could be reused from the Pong game of the last chapter.

The next chapter focuses a little bit more on game programming and how to build a game with several components. In this chapter you saw the usefulness of the helper classes and now you are ready to extend this idea to your game code, which is important for creating more complex games.

Here’s a recap of what you have learned in this chapter:

• Use helper classes wherever possible, put code to methods or helper classes especially if you have used it more than twice.

• Always write unit tests first and then work on the implementation.

• Keep the unit tests simple. You don’t have to waste time writing overly complex unit tests for helper classes or make static unit tests more complex than the game itself. Unit tests are not important for the final game (in fact they are not even included thanks to the #if DEBUG directives) and they are only used to make your life easier and help you to test and reuse new and existing code.

• When changing code, always run the tests to make sure everything still works correctly:

  • Use TestDriven.Net to run single tests or run every test of a class or namespace in the Solution Explorer.

  • Alternatively, use the NUnit GUI to test all unit tests of your assembly. For static unit tests use the Program class and start the tests manually.

  • Test the most complicated parts of your game as much as possible, like the collision testing in Breakout.