Probando WinForms/CompositeUI GUI con SpecFlow, White, Spring y MS Test

Question

Tengo una aplicación de escritorio C# (CompositUI/WinForms). Esta aplicación se conecta a un servicio web usando SmartClient. Mi tarea es introducir pruebas (de actualización) a esta aplicación, utilizando frameworks SpecFlow y White. Para probar solo la GUI, necesito burlarme de las llamadas al servicio web. La clase que se conecta a ella se está inyectando a través de Spring.net. Mi tarea es probar que la aplicación pueda simular la llamada al servicio web durante las pruebas, es decir, mi código de prueba debe controlar lo que hará mi simulacro. El problema: el método que inicia la GUI simplemente no devuelve el control al hilo que lo ha invocado. Como resultado, no podemos controlar la GUI y los simulacros.

lo que las preguntas que tengo en este punto son:

• es factible que (y si es así - ¿Cómo hacerlo) para iniciar la interfaz gráfica de usuario de hilo separado y tener un control posterior a la rosca prueba?

• ¿Cuáles serían otras posibilidades de ejecutar pruebas GUI, que me permitirían tener el control sobre las inyectadas?

Answer 1

esencial para poner a prueba su interfaz de usuario .NET va a tener que utilizar un conjunto de herramientas de MVVM o crear uno para que pueda configurar su solución para poner a prueba los métodos utilizados por la interfaz de usuario. Hay una serie de marcos para .net que admiten esto se puede encontrar en Wikipedia.

Los elementos básicos que subyacen a todas las pruebas de interfaz de usuario de MVVM son un marco DI/IOC, que deberá elegir también.

Básicamente, usted crea una clase ViewModel que puede probar. Para ver un ejemplo de prueba unitaria con WPF - http://www.markermetro.com/2010/07/technical/mvvm-light-and-unit-testing-example/

Ahora hay algunos inconvenientes para pensar. En primer lugar, .NET WinForms no va a tener cambios importantes en M $ (GRACIAS A BUNCH!) Y XAML/WPF no tiene una ruta de actualización. MS $ indicó que los desarrolladores deberían comenzar a utilizar los diseñadores de interfaz de usuario de WPF para proyectos de escritorio en el futuro. El número de marcos de MVVM que admiten WinForms es limitado, por lo que es posible que deba transferir el suyo a través de DI, pero eche un vistazo a la siguiente discusión de StackOverflow sobre el tema.

En segundo lugar los formularios .NET a WPF a Windows Phone a la interfaz de usuario Web a problemas de implementación de UI de Metro. El equipo P & P de Microsoft creó Prism para xaml/WPF tiene algunos patrones anti inyección de Dependencia (Service Locator es MALO) de acuerdo con el libro Mark Seemann and his Dependency Injection in .NET. Prism no se ha actualizado a Metro y se ha rediseñado, lo que confunde a los adoptantes y lo hace parcialmente redundante. Básicamente, mi punto es que conseguir un marco para permitir que la UI de su aplicación avance es difícil.