recomiendo dos libros: Test Driven Development by Example, por Kent Beck. Es un excelente libro sobre TDD, que disfruto particularmente porque él repasa un ejemplo, que es muy útil para captar el ritmo y el proceso de pensamiento. Por otro lado, es un poco ligero en la burla. Para eso leería The Art of Unit Testing, por Roy Osherove. Como sugiere el título, no se centra específicamente en TDD, sino en cómo escribir buenas pruebas unitarias; él tiene una buena cobertura en simulacros y trozos.
En cuanto a lo que debe burlarse, la idea de burlarse es permitirle aislar la clase/función que está probando del resto del entorno, para que pueda probar su comportamiento contra un entorno falso que usted controla. En ese marco, no deberías burlarte de la clase, sino más bien cosas de las que depende.
Un ejemplo trivial: si tuvieras una clase usando un registrador, probar que la clase "escribe" al registrador sería muy doloroso, y podría involucrar cosas como verificar si el registrador ha escrito en un archivo de texto. Esta no es una buena idea en muchos niveles, comenzando por el hecho de que a su clase no le importa cómo el registrador hace su trabajo específicamente. En ese caso, usted reemplazaría la instancia de Logger en su clase con un Logger falso, burlado, y luego podrá verificar que su clase está llamando al Logger en los momentos apropiados, sin preocuparse por lo que hace exactamente el registrador.
En cuanto a la inicialización del servidor: una prueba unitaria suele estar en la memoria, sin dependencias con el entorno, por lo que si está haciendo TDD, probablemente no tenga que hacer eso. En general, demasiado (¿algún?) Código de inicialización en una prueba unitaria es una mala señal.
Esto sugiere que está buscando más pruebas de aceptación/pruebas de estilo BDD. Recomiendo este artículo reciente en MSDN Magazine en Behavior-Driven Development with SpecFlow and WatiN; explica cómo puede desarrollarse de manera experimental, desarrollando juntas pruebas de alto nivel que verifican que la aplicación está haciendo lo que el usuario quiere (pruebas de aceptación, donde podría ejecutar su servidor y aplicación reales), y que lo está haciendo al tener pequeñas piezas de código que hacen lo que el desarrollador pretende (pruebas unitarias).
Espero que esto ayude, y pruebas felices!
Hay ciertas cosas que debo hacer para lograr cualquier cosa, porque las cosas que deseo probar generalmente están relacionadas con algún elemento que se crea una instancia cuando el servidor se enciende. Así que tengo que ejecutar mi compilador de scripts (que construye un dll e incluye su ensamblaje) e inicializar y configurar esos archivos (es decir, invocar llamadas a métodos estáticos en bastantes scripts) – bevacqua
+1, especialmente para el libro de Osherove. ¡Gran lectura! – TrueWill