Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

24.1. Splitting Out Test Materials

This subject is close to my heart. It helps not only with application maintenance, but also when deploying to production environments. You need to ensure that all development and test materials are completely separated from the production releases. It is very easy to get carried away during development and forget this and when releases are being compiled for production use, they suddenly contain a lot of test matter. This could be something as simple as including a unit test class in the same library as the core code. Or it could be the inclusion of test configuration settings in the live configuration files. You also need to consider naming conventions to ensure that test items can be easily identified. It would be very easy in a plug-in architecture to accidentally wire-up a test component if it wasn't named correctly. For instance, consider the following simple example:

<AccountData assemblyName="DataEntities" className="AccountData" />

Is this the real class or a test class? Without it being named correctly, it would also be very easy to wire-up the wrong class. However, when the components are named correctly, this can be avoided. Furthermore, consider the following example:

<AccountData assemblyName="DataEntities" className="AccountDataTestStub" />

This implies that the DataEntities library contains both a real account data object and one designed specifically for testing. In the early days of modeling, you could have a DataEntities library ...