unit-testing - unitarias - unit test c# visual studio 2017
¿Cómo puedo probar la unidad de una GUI? (12)
Los cálculos en mi código están bien probados, pero debido a que hay tanto código de GUI, mi cobertura de código general es más baja de lo que me gustaría. ¿Hay alguna guía sobre el código GUI para pruebas unitarias? ¿Tiene sentido?
Por ejemplo, hay gráficos en mi aplicación. No he podido averiguar cómo automatizar la prueba de los gráficos. Se necesita un ojo humano, AFAIK, para verificar si el gráfico es correcto.
(Estoy usando Java Swing)
Aquí hay algunos consejos:
Intente eliminar la mayor cantidad de código que pueda de la GUI (tenga el controlador y el objeto modelo) de esta manera podrá probarlos sin la GUI.
Para el gráfico, debe probar el valor que proporciona al código que genera el gráfico.
Hay Selenium RC , que automatizará las pruebas de una interfaz de usuario basada en web. Grabará acciones y las reproducirá. Aún necesitará revisar las interacciones con su UI, de modo que esto no ayudará con la cobertura, pero puede usarse para construcciones automáticas.
Las pruebas son una forma de arte. Estoy de acuerdo en que se debe eliminar la lógica de la GUI tanto como sea posible. Entonces podemos enfocar nuestras pruebas unitarias allí. Al igual que cualquier otra cosa, las pruebas se tratan de reducir el riesgo. No siempre es necesario probar todo, pero muchas veces lo mejor es dividir las diferentes pruebas en diferentes áreas.
La otra pregunta es qué estás tratando de probar en la capa de IU. La prueba de IU es la prueba más costosa porque normalmente lleva más tiempo crear, mantener y es la más frágil. Si prueba la lógica para saber que las coordenadas son correctas antes de intentar trazar la línea, ¿qué está probando específicamente? Si quieres probar un gráfico, se dibuja una línea roja. ¿Puedes darle un conjunto de coordenadas predeterminadas y probar si ciertos píxeles son rojos o no rojos? Como se sugiere arriba, las comparaciones de mapa de bits funcionan, Selenium, pero mi objetivo principal no es sobreexigir la GUI sino probar la lógica que ayudará a crear la interfaz de usuario y luego centrarme en qué parte de la UI se rompe o es sospechosa y enfocar un puñado de pruebas ahí.
Lo que deduzco de su pregunta es que está buscando una forma automatizada para probar el comportamiento de su GUI en detalle, el ejemplo que da es probar si una curva se dibujó correctamente.
Los marcos de pruebas unitarias proporcionan una manera de hacer pruebas automatizadas, pero creo que el tipo de pruebas que desea hacer son pruebas de integración complicadas que verifican el comportamiento correcto de una multitud de clases, entre las cuales se encuentran las clases de su kit de herramientas GUI / biblioteca. no debería querer probar
Sus opciones dependen en gran medida de qué plataformas / herramientas / marcos utiliza: por ejemplo, una aplicación que utiliza Qt como su marco de GUI puede usar Squish para automatizar sus pruebas. Verifica los resultados de sus pruebas una vez y las pruebas subsiguientes ejecutadas automáticamente comparan los resultados con los resultados verificados.
Los diseños como MVP y MVC normalmente intentan extraer tanta lógica de la GUI real como sea posible. Un artículo muy popular sobre esto es "The Humble Dialog Box" de Michael Feathers. Personalmente, he tenido experiencias mixtas al tratar de sacar la lógica de la interfaz de usuario, a veces ha funcionado muy bien y otras veces ha sido más problemático de lo que vale. Sin embargo, está fuera de mi área de experiencia.
Por lo que sé, esto es bastante complicado, y realmente depende del idioma: numerosos lenguajes tienen su propia forma de probar GUI, pero si realmente necesitas probar la GUI (a diferencia de la interacción modelo / interfaz gráfica de usuario), a menudo tienes que simular un usuario real haciendo clic en los botones. Por ejemplo, el marco SWT utilizado en Eclipse proporciona SWTBot , JFCUnit ya ha sido mencionado, Mozilla tiene su propia forma de simular esto en XUL (y por lo que he leído en sus blogs, estas pruebas parecen ser bastante frágiles).
A veces hay que tomar una captura de pantalla y probar el renderizado perfecto (creo que Mozilla hace esto para verificar páginas correctamente renderizadas); esto requiere una configuración más larga, pero podría ser lo que necesita para los gráficos. De esta forma, cuando actualiza su código y se rompe una prueba, debe verificar manualmente si la falla fue real, o mejoró el código de representación gráfica para generar gráficos más bonitos y necesita actualizar las capturas de pantalla.
Por supuesto, la respuesta es usar MVC y mover tanta lógica fuera de la GUI como sea posible.
Una vez dicho esto, escuché de un compañero de trabajo hace mucho tiempo que cuando SGI trasladaba OpenGL a un nuevo hardware, tenían un conjunto de pruebas unitarias que dibujaban un conjunto de primativos en la pantalla y luego calculaban una suma MD5 del frame buffer. Este valor podría entonces ser comparado con buenos valores de hash conocidos para determinar rápidamente si la API es precisa por píxel.
Puede probar que UISpec4J es una biblioteca de pruebas funcionales y / o de código abierto para aplicaciones Java basadas en Swing ...
Puede usar JFCUnit para probar su GUI, pero los gráficos pueden ser más desafiantes. En un par de ocasiones, tomé instantáneas de mi GUI y las comparé automáticamente con una versión anterior. Si bien esto no proporciona una prueba real, sí le avisa si una compilación automática no produce el resultado esperado.
Si está utilizando Swing, FEST-Swing es útil para manejar su GUI y probar las afirmaciones. Hace que sea bastante sencillo probar cosas como "si hago clic en el botón A, se mostrará el cuadro de diálogo B" o "si selecciono la opción 2 del menú desplegable, todas las casillas de verificación se deseleccionarán" .
El escenario gráfico que mencionas no es tan fácil de probar. Es bastante fácil obtener cobertura de código para los componentes de la GUI simplemente al crearlos y mostrarlos (y quizás guiarlos con FEST). Sin embargo, hacer afirmaciones significativas es la parte difícil (y la cobertura del código sin afirmaciones significativas es un ejercicio de autoengaño). ¿Cómo se prueba que el gráfico no se dibujó al revés o demasiado pequeño?
Creo que solo tienes que aceptar que algunos aspectos de las GUI no se pueden probar de manera efectiva mediante pruebas unitarias automatizadas y que tendrás que probarlos de otras maneras.
Window Licker para Swing y Ajax
Puede intentar usar Cucumber and Swinger para escribir pruebas de aceptación funcional en inglés simple para aplicaciones de GUI de Swing. Swinger usa la biblioteca Jemmy de Netbeans debajo del capó para conducir la aplicación.
Pepino te permite escribir pruebas como esta:
Scenario: Dialog manipulation
Given the frame "SwingSet" is visible
When I click the menu "File/About"
Then I should see the dialog "About Swing!"
When I click the button "OK"
Then I should not see the dialog "About Swing!"
Echa un vistazo a esta demostración de video de Swinger para verla en acción.