¿Cómo puedo escribir una prueba de unidad para una clase de controlador que usa formas de win para vistas?

Question

¿Alguien ha sido capaz de unir con éxito métodos de prueba que, por necesidad, están acoplados a la clase System.Windows.Forms.Form?

Recientemente he estado trabajando en una aplicación C# winforms, tratando de construirlo con una estructura MVC. Esto es bastante difícil, dado que el marco no está realmente construido con esto en mente.

Sin embargo, se pone aún más difícil cuando se lanzan pruebas unitarias en la mezcla. Me he estado asegurando de que mis controladores no estén acoplados a clases de vista concretas, de modo que pueda usar un stub/mock para probar la unidad. Pero hacer referencia a la clase de formulario en algún lugar es inevitable, y estos métodos deben ser probados.

He estado usando Moq porque tiene algunas buenas características de seguridad tipo, y permite burlarse de tipos de concreto. Pero desafortunadamente, no me permite "esperar" llamadas a métodos o propiedades en un tipo concreto que no sean ni virtuales ni abstractos. Y dado que la clase Form no se construyó con subclases en mente, este es un gran problema. Necesito poder simular la clase Form para evitar que se creen ventanas reales, por ejemplo, "esperando" ShowDialog.

Así que no puedo ejecutar ninguna prueba unitaria que interactúe mucho con las subclases de Formulario, que son mis puntos de vista.

¿Hay alguien por ahí que haya probado con éxito este tipo de código? ¿Cómo lo hiciste?

¿Es esto algo que otros marcos burlones pueden evitar? ¿Los métodos basados ​​en cuerdas utilizados por otros marcos de burla estarán sujetos a las mismas restricciones? ¿Puedo escribir mis propias clases simuladas de mano dura explícitas o la falta de miembros virtuales me impedirá también suprimir el comportamiento de la ventana?

¿O hay alguna manera en que no he pensado en estructurar mis clases para que el código acoplado a formularios termine en métodos y clases de complejidad trivial, de modo que pueda escapar sin probarlos de manera explícita, sin mi ¿la conciencia me está golpeando por eso?

Answer 1

El mejor método que he escuchado/usado para probar unidades con elementos GUI es el patrón/método Humble Dialog. En esencia, los formularios son solo la interfaz, y todo el trabajo real se realiza en otras clases. Usted prueba las clases que brindan la funcionalidad, y luego simplemente une sus eventos GUI a los métodos apropiados en esas clases.

Answer 2

Mi idea actual es que quizás tenga que usar composición en lugar de herencia con la clase Form, para desacoplar los controladores de ella.

Esto tiene la desventaja de que cada vez que necesito usar un miembro de la clase Form que no planeé, necesito agregarlo explícitamente a mi interfaz de vista.