Trabajé en un entorno que estaba en proceso de migrar a un modelo de operaciones TDD. Para algunas cosas como monitorear scripts esto funcionó muy bien. Utilizamos buildbot para configurar el entorno de prueba y ejecutar las pruebas. En este caso, se acerca a TDD desde la perspectiva del "Código heredado". En TDD "Legacy Code" es un código existente que no tiene pruebas. Entonces, las primeras pruebas no fallan, definen la operación correcta (o esperada).
Para muchos trabajos de configuración, el primer paso es probar si el servicio puede analizar la configuración. Muchos servicios brindan algunas facilidades para hacer esto. Nagios tiene modo de verificación previa, cfagent no tiene acto, apache, sudo, bind y muchos otros tienen instalaciones similares. Esto es básicamente una pelusa para las configuraciones.
Un ejemplo sería si usa apache y archivos de configuración separados para diferentes partes, también puede probar las partes, simplemente use un archivo httpd.conf diferente para envolverlas y ejecutarlas en su máquina de prueba. Luego puede probar que el servidor web en la máquina de prueba da los resultados correctos allí.
En cada paso del camino sigues el mismo patrón básico. Escriba una prueba, apruebe la prueba, refactorice el trabajo que ha realizado. Como se mencionó anteriormente, al seguir este camino, las pruebas pueden no siempre fallar en la forma TDD aceptada.
Rik