c++ - test - Unidad de prueba de aplicaciones de interfaz de usuario de MFC?

google unit test framework for c++

Question

¿Cómo se prueba una unidad de una aplicación de interfaz de usuario de MFC grande?

Tenemos algunas aplicaciones grandes de MFC que han estado en desarrollo durante muchos años, utilizamos algunas herramientas de control de calidad estándar para ejecutar scripts básicos para verificar los fundamentos, archivos abiertos, etc. Estos son ejecutados por el grupo de control de calidad publicar la compilación diaria.

Pero nos gustaría introducir procedimientos para que los desarrolladores individuales puedan construir y ejecutar pruebas en los diálogos, menús y otros elementos visuales de la aplicación antes de enviar el código a la compilación diaria.

He oído hablar de técnicas como los botones de prueba ocultos en los cuadros de diálogo que solo aparecen en las versiones de depuración, ¿hay algún conjunto de herramientas estándar para esto?

El entorno es C ++ / C / FORTRAN, MSVC 2005, Intel FORTRAN 9.1, Windows XP / Vista x86 y x64.

Answer 1

Aunque no es perfecto, lo mejor que he encontrado para esto es AutoIt http://www.autoitscript.com/autoit3

"AutoIt v3 es un lenguaje gratuito de scripting similar al BASIC diseñado para automatizar la GUI de Windows y el scripting general. Utiliza una combinación de teclas simuladas, movimiento del mouse y manipulación de ventana / control para automatizar tareas de una manera que no es posible o confiable con otras idiomas (por ejemplo, VBScript y SendKeys). AutoIt también es muy pequeño, autónomo y se ejecutará en todas las versiones de Windows listas para usar, sin necesidad de molestos "tiempos de ejecución".

Esto funciona bien cuando tiene acceso al código fuente de la aplicación que se maneja, porque puede usar el número de ID de recurso de los controles que desea conducir. De esta forma, no tiene que preocuparse por los clics del mouse simulados en determinados píxeles. Desafortunadamente, en una aplicación heredada, es posible que descubra que la ID del recurso no es única, lo que puede causar problemas. Sin embargo. es muy sencillo cambiar los ID para que sean únicos y reconstruir.

El otro problema es que encontrará problemas de tiempo. No tengo una solución probada y verdadera para estos. Prueba y error es lo que he usado, pero esto claramente no es escalable. El problema es que la secuencia de comandos de AutoIT debe esperar a que la aplicación de prueba responda a un comando antes de que la secuencia de comandos emita el siguiente comando o verifique la respuesta correcta. A veces no es fácil encontrar un evento conveniente para esperar y observar.

Mi sensación es que, al desarrollar una nueva aplicación, insisto en una forma consistente de señalar "LISTO". ¡Esto sería útil para los usuarios humanos, así como para los scripts de prueba! Esto puede ser un desafío para una aplicación heredada, pero quizás pueda introducirla en puntos problemáticos y extenderla lentamente a toda la aplicación a medida que continúa el mantenimiento.

Answer 2

Aunque no puede manejar el lado de UI, pruebo el código MFC de la unidad utilizando la biblioteca Boost Test. Hay un artículo de Code Project sobre cómo comenzar:

Diseñando objetos robustos con Boost

Answer 3

Bueno, tenemos una de estas enormes aplicaciones de MFC en el lugar de trabajo. Es un dolor gigantesco para mantener o extender ... es una gran bola de barro ahora, pero rastrilla en el moolah. De todos modos

• Usamos Rational Robot para hacer pruebas de humo y similares.

• Otro enfoque que ha tenido cierto éxito es crear un lenguaje específico de producto pequeño y pruebas de guiones que usen VBScript y algunos controles manejan la magia de espionaje. Convierta acciones comunes en comandos. Por ejemplo, OpenDatabase sería un comando que a su vez inyectará los bloques de script necesarios para hacer clic en Menú principal> Archivo> "Abrir ...". A continuación, crea hojas de Excel que son una serie de dichos comandos. Estos comandos también pueden tomar parámetros. Algo así como una Prueba FIT ... pero más trabajo. Una vez que tenga la mayoría de los comandos comunes identificados y los scripts listos. Se trata de seleccionar y montar scripts (etiquetados por CommandID) para escribir nuevas pruebas. Un examinador de pruebas analiza estas hojas de Excel, combina todos los pequeños bloques de script en un script de prueba y lo ejecuta.

  1. OpenDatabase "C: / tests / MyDB"
  2. OpenDialog "Agregar modelo"
  3. AddModel "M0001", "MyModel", 2.5, 100
  4. Presiona OK
  5. SaveDatabase

HTH

Answer 4

Como mencionó MFC, asumí que tiene una aplicación que sería difícil obtener bajo un arnés de prueba automático. Observará los mejores beneficios de los marcos de pruebas unitarias cuando construya pruebas mientras escribe el código. Pero intentar agregar una nueva característica de forma guiada por pruebas a una aplicación que no está diseñada para ser comprobada ... puede ser un trabajo duro. y bien frustrante.

Ahora lo que voy a proponer es definitivamente un trabajo duro ... pero con algo de disciplina y perseverancia verá el beneficio lo suficientemente pronto.

• En primer lugar, necesitará un poco de respaldo de gestión para que las nuevas correcciones tarden un poco más. Asegúrese de que todos entiendan por qué.
• Luego compre una copia del libro de WELC . Léelo de principio a fin si tiene tiempo o, si está en apuros, explore el índice para encontrar el síntoma que presenta su aplicación. Este libro contiene muchos buenos consejos y es justo lo que necesita al intentar que el código existente sea comprobable. texto alternativo http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL160_AA115_.jpg
• Luego, por cada nueva corrección / cambio, dedique un tiempo y comprenda el área en la que va a trabajar. Escriba algunas pruebas en una variante xUnit de su elección (disponible gratuitamente) para ejercitar el comportamiento actual.
• Asegúrate de que todas las pruebas pasen. Escriba una prueba nueva que ejercite el comportamiento necesario o el error.
• Escriba el código para hacer que pase esta última prueba.
• Refactoría sin piedad dentro del área sometida a pruebas para mejorar el diseño.
• Repita para cada nuevo cambio que tenga que hacer en el sistema a partir de ahora. No hay excepciones a esta regla.
• Ahora la tierra prometida : pronto comenzarán a aparecer islas de códigos bien probados. Cada vez más código se incluiría en el conjunto de pruebas automáticas y los cambios serán cada vez más fáciles de realizar. Y eso es porque lenta y seguramente el diseño subyacente se vuelve más comprobable.

La salida más fácil fue mi respuesta anterior. Esta es la salida difícil pero correcta.

Answer 5

En realidad, hemos estado usando Rational Team Test, luego Robot, pero en discusiones recientes con Rational descubrimos que no tienen planes de admitir aplicaciones Native x64 que se centren más en .NET, por lo que decidimos cambiar las herramientas de control de calidad automático. Esto es genial, pero los costos de licencia no nos permiten habilitarlo para todos los desarrolladores.

Todas nuestras aplicaciones admiten una API COM para la creación de scripts, que hacemos la prueba de regresión a través de VB, pero esto prueba la API, no la aplicación como tal.

Idealmente, estaría interesado en cómo las personas integran cppunit y marcos de pruebas de unidades similares en la aplicación a nivel de desarrollador.

Answer 6

Depende de cómo esté estructurada la aplicación. Si la lógica y el código GUI están separados (MVC), entonces probar la lógica es fácil. Eche un vistazo a Michael Feathers "Humble Dialog Box" (PDF).

EDITAR: Si lo piensas bien, deberías refactorizar muy cuidadosamente si la aplicación no está estructurada de esa manera. No hay otra técnica para probar la lógica. Las secuencias de comandos que simulan clics simplemente están rascando la superficie.

En realidad es bastante fácil:

Asuma que su control / ventana / lo que sea cambia el contenido de un cuadro de lista cuando el usuario hace clic en un botón y desea asegurarse de que el cuadro de lista contenga las cosas correctas después del clic.

1. Refactor para que haya una lista separada con los elementos para mostrar en el cuadro de lista. Los elementos se almacenan en la lista y no se extraen de donde provengan sus datos. El código que hace que la lista enumere cosas solo sabe sobre la nueva lista.
2. Luego, crea un nuevo objeto controlador que contendrá el código lógico. El método que maneja el botón clic solo llama a mycontroller-> ButtonWasClicked (). No sabe sobre el listbox ni nada más.
3. MyController :: ButtonWasClicked () hace lo que necesita hacerse para la lógica prevista, prepara la lista de elementos y le dice al control que se actualice. Para que funcione, debe desacoplar el controlador y el control creando una interfaz (clase virtual pura) para el control. El controlador solo conoce un objeto de ese tipo, no el control.

Eso es. El controlador contiene el código lógico y conoce el control solo a través de la interfaz. Ahora puede escribir una prueba de unidad regular para MyController :: ButtonWasClicked () burlándose del control. Si no tienes idea de lo que estoy hablando, lee el artículo de Michaels. Dos veces. Y de nuevo después de eso.
(Nota para mí: debe aprender a no hablar tanto)

Answer 7

Me doy cuenta de que esta es una pregunta anticuada, pero para aquellos de nosotros que todavía trabajamos con MFC, el Marco de Prueba de Unidad de Microsoft C ++ en VS2012 funciona bien.

El procedimiento general:

1. Compile su proyecto MFC como una biblioteca estática
2. Agregue un nuevo Proyecto de Prueba de Unidad Nativa a su solución.
3. En el Proyecto de prueba, agregue su proyecto MFC como referencia.
4. En Propiedades de configuración del Proyecto de prueba, agregue los directorios Incluir para sus archivos de encabezado.
5. En el Enlazador, las opciones de entrada agregan su MFC.lib; nafxcwd.lib; libcmtd.lib;
6. En "Ignorar bibliotecas predeterminadas específicas", agregue nafxcwd.lib; libcmtd.lib;
7. En General, agregue la ubicación de su archivo lib exportado de MFC.

El https://.com/questions/1146338/error-lnk2005-new-and-delete-already-defined-in-libcmtd-libnew-obj tiene una buena descripción de por qué necesita nafxcwd.lib y libcmtd.lib .

La otra cosa importante a verificar en proyectos heredados. En Propiedades de configuración general, asegúrese de que ambos proyectos estén usando el mismo ''Conjunto de caracteres''. Si su equipo MFC usa un conjunto de caracteres de varios bytes, también necesitará la prueba de MS para hacerlo.