I finished reading the ebook Foundations of Programming: Building Better Software by Karl Seguin which is available at the previous link. The book focuses on concepts of improving coding practice using some Agile methodologies and incorporating ideas from both the .NET (MSDN) and ALT.NET (abstract concepts with more specific implementations). Seguin brings up good elements of Domain Driven Design vs Data Driven Design where the behavior of the system rather then on the data, which allows for a more flexible system that can be refactored with different data as the needs arise. The book also focuses on Dependency Injection as a way of decoupling certain systems and increasing the ease of Unit Testing those systems. Seguin also suggests that if something is difficult to unit test it is likely that method or function is likely tightly coupled and could be refactored to produce better code (code that is difficult to test means it is likely difficult to use).
While the book does deal with more application specific elements (Object Relational Matching using NHibernate and Rhinomock for the .Net framework) the concept of unit testing when applied to games does bring up some interesting comparisons. The data within games is difficult to test for a majority of reasons (if you ever talk to game testers/QA they will be spending a lot of their time repeating the same things over and over again with only slight alterations on each iteration). One of the difficulties is the complexity of data that comes in at runtime during a game, often relying on art for collision information, state information from a sync server and lots of potential for any sort of race conditions that a unit test would obviously not cover. This does not mean that we should dismiss unit testing but instead focus on testing what we can, by writing code that can be easily unit tested we are likely writing simpler and better encapsulated code then would likely be produced without unit testing. This is also a large benefit for testing (and refactoring) the core elements of the system that do not rely on as much art, server or runtime information. While testing does take time, it is invaluable in helping find issues before they become bugs and incredibly useful in verifying the same behaviors during any refactiong.
As a whole it was a quick and informative read and would recommend this to anyone interested in improving code and an interest in unit testing (plus the price is right :P)
This got me interested in more specific refactoring so I may be looking at more code quality books in the near future.
Bye for now,