Programming considered as a game
A game can be defined as an activity undertaken within voluntary constraints for the enjoyment of overcoming a challenge. To code well means not just to play within the rules of language syntax and semantics, but to recognize and pursue higher ends, such as clarity of structure and allowance for future change. Of these, the former might be compared to making a good pass to a team mate, and the latter to anticipating the possible moves of an opponent. Programming is a game in which both the team mate and the opponent can turn out to be yourself.
When writing tests, the game is this: could an adversary make one change that breaks your code but evades detection by your tests?
Notes
Defining the notion of game has been a problem for philosophers. The definition above is based on that of Bernard Suits (in his 1978 book, The Grasshopper), to which C. Thi Nguyen (interviewed by Sean Carroll) drew my attention. According to Suits, a game's rules must impose some artificial inefficiency, but I cannot see this as a necessary characteristic -- though, if you do, you can consider whether a program is to be written in Python, or C, or assembly. Similarly, although I use the word "voluntary" above, that does not appear to me to be essential. Another objection: if one is doing something for payment then it cannot be a game. This too is a mistake: if you are happily absorbed in a problem, does the fact that you are being paid to solve it (something that you have quite forgotten in your concentration) really change what is going on? Professional footballers still play games. Jesper Juul's Heart of Gameness is a good analysis.