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

Question

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

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

Sin embargo, se vuelve aún más difícil cuando arrojas pruebas de unidad a la mezcla. Me he asegurado de que mis controladores no estén acoplados a clases de vista concretas, de modo que pueda usar un dispositivo auxiliar / simulacro para la prueba de la unidad. Pero hacer referencia a la clase Form en alguna parte es inevitable, y estos métodos deben probarse.

He estado usando Moq porque tiene algunas características de seguridad de tipo muy buenas, y Permite burlarse de los tipos de hormigón. Pero desafortunadamente, no me permite " esperar " Llamadas a métodos o propiedades en un tipo concreto que no son virtuales ni abstractos. Y como la clase Form no se creó teniendo en cuenta las subclases, este es un gran problema. Necesito poder simular la clase Form para evitar que se creen ventanas reales, esperando " " ShowDialog, por ejemplo.

Por lo tanto, no puedo ejecutar ninguna prueba unitaria que haga mucha interacción con las subclases de Form, que son mis vistas.

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

¿Es esto algo que otros marcos de burla pueden sortear? ¿Los métodos basados ??en cadenas utilizados por otros marcos de simulacros estarían sujetos a las mismas restricciones? ¿Puedo escribir mis propias clases explícitas de simulación de mano larga o la falta de miembros virtuales me impedirá poder suprimir el comportamiento de la ventana de esa manera también?

¿O hay alguna forma en la que no haya 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 probarlas de forma explícita, sin mi conciencia? dándome una paliza por ello?

Answer 1

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

Answer 2

Mi idea actual es que debo usar la composición en lugar de la 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é, debo agregarlo explícitamente a la interfaz de mi vista.