Unidad de Prueba de una aplicación WPF 'legado'

Question

El producto que he estado trabajando en ha estado en desarrollo durante los últimos seis años. Comenzó como un portal de entrada de datos en una aplicación genérica legado parte de WPF / parte increíblemente compleja. El sistema ha sido desarrollado por todos estos años sin una sola prueba de unidad en su seno. Ahora, el punto se ha planteado un marco global de las pruebas unitarias. Se me ha contratado recientemente a trabajar sobre este producto y han encargado de conseguir la 'Prueba' en orden. Dado que el equipo que trabajó en el producto durante los últimos seis años adoptó 'ágil', el proyecto carece de la documentación de las reglas de negocio o cualquier otro documento de diseño.

He estado tratando de pruebas de la unidad de escritura para algunos de los módulos. Pero no estoy seguro de qué Mock, cómo configurar mi dispositivo de prueba y, finalmente, lo que prueba para, desde una mirada casual de los métodos no revela sus intenciones. Además, se ha llegado a mi conocimiento que el código no se ha desarrollado con una metodología particular en mente.

Dada la situación, me preguntaba si la buena gente de Stackoverflow me podían ofrecerle algunos consejos sobre la manera de salvar esta situación. He oído sobre el libro 'Utilización del código de legado' que tiene algo que decir sobre esta situación general, pero yo estaba pensando en conseguir algunos consejos de personas que se han encontrado con situaciones similares dentro de la pila de tecnología (C #, Visual Basic, C ++ ,. NET 3.5 , WCF, SQL Server 2005).

Answer 1

En mi opinión, la mejor manera es comenzar por "estabilizar" la funcionabilidad código actual usando las pruebas de integración. Trate de crear pruebas que tiene un punto que no es probable que cambie más adelante empezar. El uso de las pruebas de integración se puede ganar la confianza de que la refactorización que vendrá más tarde para la unidad de pruebas no están rompiendo nada.

El siguiente paso es a prueba de la unidad el código. Si estás libre de refactorizar el código puede empezar a separar la lógica de clases (por ejemplo, la lógica adicional en capa de vista) y añadir pruebas de unidad a ellos. Utilizando este proceso también llegar a conocer mejor el código del producto.

lectura

Es muy recomendable Trabajo con el código heredado , muchos de los problemas que vamos a encontrar soluciones ya tiene:)

Unidad de código de prueba legado puede ser un desafío a veces, dependiendo del código existente y de la cantidad que puede cambiar el código. Puede utilizar algunas herramientas, por ejemplo para escribir pruebas de integración que puede utilizar el marco blanca para automatizar la interfaz gráfica de usuario. Otra herramienta que puede utilizar para escribir las pruebas unitarias sin forzar cambios importantes en el código es Typemock aislador ( descargo de responsabilidad - I en el trabajo Typemock ), que permite simular la mayor parte de dependencias sin cambiar el código de producción. Hay muchas otras herramientas que pueden facilitar el proceso, tratar de encontrar y hacer el mejor uso de ellos:)

Answer 2

@sc_ray: Sé que esto puede sonar bastante obvio, pero creo que antes de empezar a escribir las pruebas contra la base de código existente, usted debe centrarse en asegurarse de que está utilizando un enfoque MVVM al interactuar con la interfaz de usuario. sobre ser una aplicación de legado no significa que tenga código de actualización de la interfaz de usuario directamente con sentencias if, pero cuanto mayor es el proyecto, más fácil es que la gente de derivación más modernos estilos de desarrollo de software.
Todo lo que digo es que me aseguraría de que estoy optimizando el uso de la unión, al mando, y todas las maravillosas instalaciones de infraestructura WPF proporciona. De lo contrario piezas importantes de su lógica de negocio no serían capaces de ser probado y que podrían ser potencialmente escribir las pruebas contra el código sea menos relevante ...