Cómo estructurar pruebas unitarias para una aplicación GUI usando C # y NUnit

Me han pedido que haga un pequeño proyecto paralelo para suministrar una aplicación simple a uno de nuestros clientes. Normalmente estaría trabajando en el código de fondo donde tengo todas mis necesidades de prueba resueltas, y todavía no he tenido el dudoso placer de escribir pruebas para la GUI, por lo que no me queda claro cómo debo configurar el código de prueba y las herramientas para un EXE.

Mi primer instinto fue simplemente incluir las pruebas con el código de la aplicación, sin embargo, eso requeriría el suministro de una serie de dependencias específicas de la prueba, que me han indicado que no envíe específicamente al cliente. Tampoco puedo sacar dinero para una herramienta de prueba especialmente diseñada, así que necesito usar las herramientas que tengo a mano ( StoryQ , RhinoMocks y NUnit), que realmente debería ser más que suficiente para probar el comportamiento de una aplicación GUI simple. Así que, hasta donde puedo ver, esto me deja tratando de lograr un buen equilibrio entre mantener el diseño realmente simple o ingeniar excesivamente a propósito por el bien de las pruebas. Parece que estoy construyendo la aplicación con la lógica de negocios en una biblioteca separada y probando contra la biblioteca como lo haría normalmente, o buscando algún otro mecanismo que me permita acceder al ejecutable sin romper módulos adicionales que el diseño de la aplicación no realmente necesito.

Editar:
Tenga en cuenta que esta pregunta trata sobre cómo estructurar la relación entre NUnit y mi ejecutable, en lugar de una DLL, y no sobre cómo separar la presentación y la lógica empresarial.
/Editar

Entonces mi pregunta es:

1. ¿Existe un método específico / recomendado para configurar una aplicación GUI simple con pruebas unitarias que me permita verificar adecuadamente el estado y el comportamiento, utilizando las herramientas que tengo a mano y sin recurrir a una ingeniería excesiva?
2. ¿Me he perdido algo fundamental sobre la forma en que se debe invocar / configurar NUnit al probar un EXE (en lugar de una DLL)?
3. ¿Me puede proporcionar o señalar en la dirección de ejemplos de cómo lograr todo esto?

Me doy cuenta de que puede haber más de una forma de hacer esto, así que estoy buscando pautas de implementación específicas basadas en su experiencia.

Mencioné en uno de mis comentarios a la respuesta de Simoraman que había pensado en un par de formas de hacer esto. Una de mis opciones era similar a la sugerencia en la respuesta de Jalayn de crear un proyecto duplicado y generar una DLL, mientras que mi otra idea era simplemente vincular a los archivos en el proyecto donde había código que quería probar. Si bien ambas opciones podrían funcionar, son menos que ideales.

En el segundo caso, tendría un desorden de dependencias de unidades para administrar a menos que realmente pudiera separar la arquitectura para minimizar las dependencias. Esto está bien para proyectos más pequeños, pero los más grandes podrían convertirse fácilmente en un verdadero desastre para administrar. Sin embargo, mi mayor resistencia a esta opción es la pura inelegancia de la misma. Claro que pudehacer que funcione, pero al hacerlo, efectivamente necesito romper la encapsulación para probar los componentes internos de un ensamblaje directamente a través de la fuente, en lugar de probar a través de las interfaces públicas, lo que en mi opinión es un gran no-no. Del mismo modo, tener un archivo de proyecto adicional significaría duplicar los esfuerzos en dos proyectos a la vez, o encontrar una manera de agregar la configuración del archivo del proyecto automáticamente a dos archivos a la vez, o recordar copiar y cambiar el nombre del campo del proyecto cada vez que construyo. Quizás esto se pueda automatizar en el servidor de compilación, pero sería difícil de administrar en el IDE. Una vez más, puede funcionar, pero es un error en el mejor de los casos, y una molestia en el peor si se equivoca.

Parece que la mejor manera es hacer lo que whatsisname comentó a mi pregunta, y simplemente incluir el EXE como referencia en el proyecto de prueba. Resulta que un EXE se trata efectivamente de la misma manera que una DLL en este caso, y puedo acceder a todas mis clases en capas para probar lo que flota en mi barco.

Creo que:

• Su código de prueba comercial debe estar en un proyecto separado, probando su biblioteca de códigos comerciales.
• Su código de prueba GUI debe estar en un proyecto separado, probando su biblioteca GUI. Ahora, cómo construir una biblioteca GUI en lugar de un ejecutable, intento responder más tarde.
• Si tiene my.namespace.biz.MyClass, su clase de prueba debe ser my.namespace.biz.MyClassTest (o MyClassTestCase).
• Si desea probar el código que se encuentra en su objetivo ejecutable, entonces debe tener una configuración que compila un EXE y otra configuración que construye una biblioteca (DLL) contra la cual iniciará sus pruebas.

Estas son las reglas que me gusta seguir, ya sea Java o C # (excepto que no hay ningún problema EXE con Java, por supuesto :-))

En cuanto a cómo configurar su entorno de prueba, me parece que tiene al menos estas dos opciones:

Usando MSBuild

Cree un clon de su archivo .proj (por ejemplo, myproject-as-dll.proj ). Cambie el OutputTypearchivo clonado de " EXE" a " Library". Con el comando MSBuild ahora puede crear una biblioteca que puede establecer como referencia en su proyecto que contiene casos de prueba de NUnit.

Me parece posible, pero nunca lo he usado con tanta honestidad, así que no estoy seguro. Además, es posible que no tenga MSBuild en su servidor de prueba de integración, y no sé si se puede separar de Visual Studio ...

Usando NAnt

Si no está familiarizado con NAnt, tendrá que buscar en Google cómo configurar sus proyectos con él. Tal vez echa un vistazo a esto , es un poco viejo, pero el autor ha comentado los archivos y NAnt Si encuentra que explica por sí mismo (. Editar: examinar su expediente más en detalle, encuentro su archivo de configuración extremadamente reutilizable ). También hace mucho más que simplemente construir, ya que ejecuta casos de prueba y lanza herramientas de cobertura de código. Ahora, admito que nunca he usado NAnt, a diferencia de su homólogo de Java y su padre "Ant", que he usado mucho, pero veo que es lo mismo y no creo que sea tan difícil de aprender.

Con esa herramienta, puede llegar a una configuración que le permitirá:

• construya todos sus proyectos (lógica de negocios, GUI, etc.) en bibliotecas separadas
• construye tus proyectos de prueba
• inicie las pruebas (esa parte específica se realiza con la tarea NUnit2 ).
• examine la cobertura de su código con la tarea NCover .

Con un poco más de código, incluso podrías:

• realizar implementaciones nocturnas en su servidor de integración
• Si NAnt está disponible en su servidor de integración, inicie pruebas de integración nocturnas con la ayuda de tareas programadas

Todo se hace sin cambiar nada en sus archivos de Visual Studio. Y, realmente, no me parece una ingeniería excesiva, es solo un archivo. Puede llevarle uno, tal vez dos días para que todo funcione, pero en mi opinión tendrá una buena configuración.

Por último, le daría al cliente todo lo necesario para construir, probar y ejecutar los proyectos. Tiendo a pensar que muestra tu profesionalismo y el hecho de que escribes código con calidad en mente (lo cual me parece que lo haces ya que estás buscando soluciones elegantes)

El hecho de que el proyecto sea pequeño (inicialmente) no significa que la arquitectura adecuada sea una ingeniería excesiva. El hecho de que desee escribir pruebas indica que su proyecto no es un truco único completamente trivial.

No mencionaste qué GUI-Framework estás utilizando. WPF MVVM (Model-View-ViewModel) es bueno y le permite escribir pruebas para toda la lógica con bastante facilidad. Con WinForms he escuchado cosas buenas sobre MVP (Model-View-Presenter)

Eche un vistazo a mi respuesta a esta pregunta: ¿Cómo configuro MVP para una solución Winforms?

De hecho, he escrito una aplicación de muestra que muestra cómo superpongo y cómo pruebo mi GUI.

leyendo su edición: use un corredor de prueba que se integre con su entorno de desarrollo. Yo uso ReSharper.

Había escrito Nunit WinForms hace unos años (6 años, supongo). Una cosa que recuerdo específicamente es que, aunque es un caso de prueba unitaria, también actúa como un caso de prueba de extremo a extremo. A veces no hay mucho que probar en un front-end (una forma simple). Entonces, aunque esté tratando de probar un cuadro de mensaje que aparece al hacer clic en un botón, está probando involuntariamente otros métodos de otras capas. Hay algunas cosas que no puede automatizar también. El aspecto, la sensación y la usabilidad no se pueden automatizar mediante pruebas unitarias automatizadas. Tendrá que ejecutar algunas pruebas manuales antes de lanzar.