unit testing - unitarias - ¿Cómo se prueba un.EXE con dll de terceros?
unit test c# visual studio 2013 (6)
Todavía estoy aprendiendo las artes oscuras de TDD y recientemente he estado tratando de aprender cómo hacer TDD en VB6 y lo que básicamente reduzco la lista era la vbunit3 gratuita y la vbunit3 más costosa.
Mi aplicación es un editor de texto enriquecido con un montón de dll de terceros y estaba recorriendo todo en Google para encontrar cómo hacer pruebas unitarias de este archivo ejecutable.
Entonces mi pregunta es ¿cómo pruebas un archivo exe? Especialmente en el contexto de VB6 y si tienes algún buen ejemplo con vbunit3 o simplementevbunit, simplemente eres un salvavidas, ya que me estoy ahogando en el material en este momento y todavía no puedo escribir una prueba de unidad todavía :(
Editar
En realidad, la aplicación consiste en muchos formularios, módulos y módulos de clase, y cuando los compilo, se convierte en un buen archivo .EXE. Y para hacer las cosas más complicadas, hay un buen número de variables globales volando.
Pero mi principal intención es probar la unidad de la parte del código o la parte más frágil. Y quiero asegurarme de que pueda mantener la prueba y el código separados. Así que pensé que la mejor manera de hacerlo es, de alguna manera, probar directamente el ejecutable a través de agregar referencia, etc.
¿Hay una mejor manera de hacer esto?
Y para hacer las cosas más complicadas, hay un buen número de variables globales volando.
La primera refactorización es transferir las variables globales a una clase en una DLL ActiveX. La propiedad de instancing de esa clase necesita establecerse en MULTIUSO GLOBAL. Cuando se establece el EXE para hacer referencia al ActiveX, las variables seguirán siendo globales, sin embargo, cuando se arranca el EXE para reemplazarlo con un arnés de prueba, el arnés puede acceder a las variables globales.
Una vez que tenga las pruebas en marcha, puede hacer más refactorizaciones para reducir el número de variables globales.
El único consejo útil que podría darte es elegir Michael Feathers Working Effectively con Legacy Code . Creo que su mayor desafío será su conjunto de herramientas, ya que sé que las herramientas para las pruebas de unidades VB6 simplemente no son tan sólidas.
También podrías intentar preguntar en el TDD Yahoo! Enumerar como sé que al menos un par de personas están usando vbunit3 allí.
Hay una diferencia entre las pruebas unitarias y las pruebas de integración. No prueba por unidad un ejecutable. Usted prueba unidades de computación pequeñas y autónomas, como un método o un procedimiento, dependiendo del idioma que esté usando. Una prueba de integración probaría componentes más grandes, como API, componentes de terceros o incluso ejecutables para asegurarse de que funcionen como se espera para un conjunto determinado de entradas (buenas o malas). Si bien puede realizar algunas pruebas de integración de API o componentes de complemento con herramientas de pruebas de unidades, no creo que encuentre muchas herramientas de pruebas de unidades que funcionen para probar ejecutables. Hay otros tipos de herramientas de prueba que harán un mejor trabajo en esto. Simplemente escribir guiones que proporcionan diferentes tipos de entradas y verificar sus resultados puede ser suficiente para muchos escenarios.
Si desea obtener más información sobre TDD y pruebas unitarias, debe aplicarlo a funciones o procedimientos en VB6, aunque recomendaría VB.NET (o C #) y realizaría un desarrollo orientado a objetos. Normalmente, las herramientas están orientadas hacia la programación estilo OO.
Los controles ActiveX en VB ahorran mucho tiempo, pero son la pesadilla del desarrollo impulsado por pruebas efectivas.
Para probar eficazmente una aplicación VB6 completa, idealmente debe tener un diseño donde el EXE sea una capa delgada sobre una DLL ActiveX que haga todo el trabajo. Los formularios implementan una interfaz y se registran con la DLL. Entonces, si tiene el Formulario de entrada de pedidos, implementará esa interfaz IOrderEntryForm y sus eventos invocarán los métodos en la clase OrderEntry ubicada en el cuadro de diálogo MyAppUI.
Para destacar en Visual Basic 6, FORMS puede IMPLEMENTAR una interfaz. El formulario luego se registra con una clase UI en su evento LOAD. Los eventos del formulario (como MyButton_Click) llaman a métodos en la clase de UI. La clase de interfaz de usuario utiliza los métodos de la interfaz de formulario para cambiar lo que se muestra. Es un trabajo extra, pero ahorra mucho tiempo para las pruebas. También mantenimiento ya que puede cambiar el aspecto del formulario siempre que la interfaz implementada permanezca igual.
Esto también significa que antes de tener algo como MYEXE-> MyActiveXDLL se convertirá en MYEXE-> MyUIDLL-> MyActiveXDLL.
Para su entorno de prueba crea una DLL ActiveX que se burla de la interfaz de usuario creando clases que implementan la interfaz de varios formularios. La DLL de UI no conoce la diferencia y usted tiene control total sobre qué entradas se envían y qué lee.
Tenga en cuenta que este tipo de patrón de diseño se menciona aquí . Lo utilicé como base para desarrollar y mantener la aplicación CAD / CAM de mi empresa para máquinas de corte de metales.
Los controles ActiveX de terceros son la perdición de este esquema. Esto se debe a que el código que hace el trabajo pesado está dentro del control mismo. Cuanto más sofisticado sea el control ActiveX, peor es el problema. La tendencia en mi empresa es reducir nuestra dependencia de los controles de terceros a favor de las aplicaciones internas.
Sin embargo, al igual que cualquier algoritmo y patrón de diseño, esto implica una llamada de juicio. ¿Cuántos problemas tiene en las áreas de su software que implican el control de texto enriquecido? Si no hay muchos, probablemente pueda salirse con la suya con un guión de prueba, ya sea manual o automático (es decir, enviando trazos de tecla a la aplicación) y usar un marco de prueba de unidad para el resto.
El elemento fundamental para usar Unit Testing en TODA tu aplicación es rellenar todo lo que puedas detrás de las interfaces. Solo haga lo que pueda por ahora y tome nota de las áreas en las que desea cambiar cuando realice un desarrollo futuro. No se desespere si no tiene una cobertura del 100% de inmediato o incluso para el próximo año.
Otra técnica para usar es hacer que su aplicación sea un EXE de ActiveX. La aplicación de prueba de su unidad puede hacer referencia a su aplicación como si fuera una DLL de ActiveX. Tendrás que investigar un poco para que funcione correctamente como hace un tiempo desde la última vez que trabajé con VB6 y estoy seguro de que hubo algunos trucos para hacerlo funcionar.
Por supuesto, puedes probar un EXE individual. Mira cuántas aplicaciones se componen de múltiples EXEs.
En cuanto a los componentes de terceros, ¿cómo abordar las pruebas con componentes estándar VB6? ¿Otros componentes de MS? Lo mismo con un componente de terceros.