Pregunta

Los cálculos en mi código están bien probados, pero debido a que hay mucho código GUI, mi cobertura general del código es más baja de lo que me gustaría. ¿Hay alguna guía sobre el código GUI de prueba de unidad? ¿Incluso tiene sentido?

Por ejemplo, hay gráficos en mi aplicación. No he podido averiguar cómo automatizar las pruebas de los gráficos. Se necesita un ojo humano, AFAIK, para verificar si la gráfica es correcta.

(Estoy usando Java Swing)

¿Fue útil?

Solución

Los diseños como MVP y MVC generalmente intentan abstraer tanta lógica de la GUI real como sea posible. Un artículo muy popular sobre esto es " El cuadro de diálogo humilde " por Michael Feathers. Personalmente, he tenido experiencias variadas al tratar de sacar la lógica de la interfaz de usuario: a veces funciona muy bien y otras veces ha sido más problemático de lo que vale. Sin embargo, está algo fuera de mi área de especialización.

Otros consejos

Por supuesto, la respuesta es usar MVC y sacar la mayor cantidad de lógica posible de la GUI.

Dicho esto, hace mucho tiempo escuché a un compañero de trabajo que cuando SGI estaba transfiriendo OpenGL a un nuevo hardware, tenían un montón de pruebas unitarias que dibujaban un conjunto de primativos a la pantalla y luego calculaban una suma MD5 del buffer de cuadros. Este valor podría compararse con valores de hash buenos conocidos para determinar rápidamente si la API es precisa por píxel.

Puede probar UISpec4J es una biblioteca de prueba de unidades y / o de código abierto para aplicaciones Java basadas en Swing. ...

Aquí hay algunos consejos:

Intente eliminar la mayoría del código que pueda de la GUI (tener controlador y modelo de objeto) 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.

Puedes intentar usar Cucumber y Swinger para escribir pruebas de aceptación funcional en inglés simple para aplicaciones Swing GUI. Swinger usa la biblioteca Jemmy de Netbeans bajo el capó para impulsar la aplicación.

El 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!"
Para verlo en acción.

Hay Selenium RC , que automatizará las pruebas de una interfaz de usuario basada en web. Registrará acciones y las repetirá. Aún deberá recorrer las interacciones con su UI, por lo que esto no ayudará con la cobertura, pero se puede usar para compilaciones automatizadas.

Las pruebas son una forma de arte. Estoy de acuerdo en que la lógica debe eliminarse GUI tanto como sea posible. Entonces podemos enfocar nuestra unidad de pruebas allí. Al igual que cualquier otra prueba, se trata 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 realmente intentando probar en la capa UI. La prueba de la interfaz de usuario es la prueba más costosa porque generalmente lleva más tiempo crearla, mantenerla y es la más quebradiza. 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 una gráfica con una línea roja se dibuja. ¿Puedes darle un conjunto de coordenadas predeterminadas y probar si ciertos píxeles son rojos o no rojos? Como se sugirió anteriormente, las comparaciones de mapas de bits funcionan, Selenium, pero mi enfoque principal sería no probar en exceso la GUI, sino probar la lógica que ayudará a crear la UI y luego enfocarse en qué parte de la UI se rompe o es sospechosa y enfocar un puñado de pruebas allí.

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, le alerta si una compilación automática no produce el resultado esperado.

Lo que deduzco de tu pregunta es que estás buscando una forma automatizada para probar tu comportamiento GUI en detalle, el ejemplo que das es probar si una curva se dibuja correctamente.

Los marcos de prueba de unidades proporcionan una forma de realizar pruebas automatizadas, pero creo que el tipo de pruebas que desea realizar son pruebas de integración complicadas que verifican el comportamiento correcto de una multitud de clases, entre las que se incluyen las clases de su conjunto de herramientas / biblioteca GUI , que no deberías querer probar.

Sus opciones dependen mucho de las plataformas / kits de herramientas / marcos que use: por ejemplo, una aplicación que usa Qt como su marco GUI puede usar Squish para automatizar sus pruebas. Verifica los resultados de sus pruebas una vez, y las pruebas ejecutadas automáticamente comparan los resultados con los resultados verificados.

Window Licker para Swing & amp; Ajax

Por lo que sé, esto es bastante complicado, y realmente depende del idioma; muchos idiomas tienen su propia forma de probar la GUI, pero si realmente necesita probar la GUI (a diferencia de la interacción modelo / gui), A menudo hay que simular un usuario real haciendo clic en los botones. Por ejemplo, el marco SWT utilizado en Eclipse proporciona SWTBot , JFCUnit ya se ha mencionado, Mozilla tiene su propia manera de simular esto en XUL (y por lo que he leído en sus blogs, estos las pruebas parecen ser bastante frágiles).

A veces, tiene que tomar una captura de pantalla y probar el renderizado de píxeles perfectos (creo que Mozilla hace esto para verificar las páginas renderizadas correctamente): esto requiere una configuración más larga, pero puede ser lo que necesite para los gráficos. De esa manera, cuando actualice su código y las pausas de prueba, tendrá que verificar manualmente la imagen si la falla fue real, o mejoró el código de representación del gráfico para generar gráficos más bonitos y necesita actualizar las capturas de pantalla.

Si está utilizando Swing, FEST-Swing es útil para impulsar su GUI y aseveraciones de prueba. Resulta bastante sencillo probar cosas como " si hago clic en el botón A, debería aparecer el diálogo B " o " si selecciono la opción 2 del menú desplegable, todas las casillas de verificación debe ser deseleccionado " .

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 con solo crearlos y mostrarlos (y quizás conducirlos 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 compruebas que el gráfico no se dibujó al revés o es demasiado pequeño?

Creo que solo tiene que aceptar que algunos aspectos de las GUI no pueden probarse de manera eficaz mediante pruebas unitarias automatizadas y que tendrá que probarlas de otras maneras.

No es su trabajo probar la biblioteca GUI. Por lo tanto, puede esquivar la responsabilidad de verificar lo que realmente se dibuja en la pantalla y ver las propiedades de los widgets, confiando en la biblioteca que representan con precisión lo que se dibuja.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top