Interfaz de usuario de prueba de unidad. ¿Cuál es una forma efectiva?

Question

Tengo una aplicación de cliente/servidor de contabilidad & donde hay varios formularios de entrada con reglas complejas de validación de datos. Estoy encontrando una manera efectiva de realizar pruebas unitarias de la interfaz de usuario.

Para las reglas de validación complejas que quiero decir:

• "Desactivar botón X si inserto un valor en el campo de texto Y"
• "Activar un cuadro combinado si inserto un valor en un campo de texto" ... ... ......

patrón más prometedores que he encontrado es sugerido por M. Fowler (http://martinfowler.com/eaaDev/ModelViewPresenter.html).

¿Tiene alguna experiencia acerca de la prueba unitaria de la interfaz de usuario? Como pila de tecnología, estoy usando: .NET 3.5 & Windows Forms Widget Library.

Answer 1

No lo llamaría "pruebas unitarias" exactamente, pero he tenido cierto éxito al ejecutar pruebas automatizadas contra una interfaz de usuario de WinForms, y también en la interfaz de usuario web usando WatiN.

Suponiendo que pueda obtener un control para la ventana de la aplicación que desea probar, debería poder crear una secuencia de comandos de una gran cantidad de código C# para probar la funcionalidad de la interfaz de usuario.

Muchas personas condenan la idea de intentar ejecutar pruebas automatizadas contra una IU, porque hay tantas cosas que no se pueden probar de esa manera. Por ejemplo, ninguna prueba automatizada notará que una fuente es fea o que un texto es confuso o que un botón está ligeramente descentrado. No hay duda, para este tipo de cosas definitivamente necesitas una persona humana inteligente que mire la pantalla.

Sin embargo, ese tipo de prueba aparte, definitivamente hay una gran variedad de pruebas repetitivas que pueden automatizarse y realizarse regularmente. La mayoría de las aplicaciones grandes tienen un lote completo de scripts de prueba de regresión que se deben realizar manualmente cada vez que una nueva versión se va a cerrar. Estas pruebas suelen ser algo para lo que se puede entrenar un mono, solo una lista de instrucciones para hacer clic en este enlace, ingresar texto, hacer clic en este botón, verificar el mensaje resultante, etc. Estas cosas son una pérdida terrible del tiempo de su QA tester, y los hace miserables, así que si pueden ser automatizados, genial. Este tipo de pruebas debe ser ejecutada automáticamente por su servidor de compilación todos los días, y podría diseñarse para ser mucho más exhaustiva que cualquier prueba manual.

Una vez más, no encontrará cosas inesperadas extrañas, pero le dará un cierto nivel de confianza de que su pequeño cambio no rompió ninguna otra pantalla que nunca escuchó al otro lado de la aplicación.

Concedido, esto da como resultado un trabajo más continuo para los desarrolladores, porque pequeños cambios en la aplicación podrían romper las pruebas por razones estúpidas, como cualquier prueba automatizada, pero debería ahorrarle mucho tiempo en pruebas y depuración. Si esto vale la pena es para usted decidir, pero creo que es una consideración que no debe descartarse tan rápido como normalmente se ve.

Answer 2

Las pruebas unitarias no son tan buenas para probar una interfaz, por definición. Las pruebas unitarias deberían probar la funcionalidad del back-end de una sola entidad. Para las pruebas funcionales, obtenga un marco para hacerlo. Considere cosas como Mercury (ahora HP) Quality Center o Performance Center. Si tienes un presupuesto, prueba Selenium.

Las pruebas funcionales son un paso adelante de las pruebas unitarias, y no deben confundirse entre sí.

Answer 3

Las pruebas de la interfaz de usuario son difíciles y generalmente se realizan mejor a un nivel de prueba más alto que las pruebas unitarias.

Controladores de prueba y lógica utilizando la separación MVC/MVP sugerida por Martin Fowler es un excelente comienzo, pero a menudo es necesario aumentar esto con herramientas de automatización como WinRunner o QTP para probar completamente la interfaz de usuario de forma automatizada.

Answer 4

Para las reglas de validación complejas que quiero decir:

* "Disable button X if I Insert a value in textfield Y" 

Estas reglas de prueba tanto del modelo y Vista, y eso es lo que les hace difícil. En su lugar, valide que cuando inserta un valor en el campo de texto Y, el modelo adquiera ese valor; que un modelo con Y vacío tiene X_ENABLED == falso, y con Y no vacío tiene X_ENABLED == verdadero; y que, dado un modelo con X_ENABLED == verdadero, el botón Vista está habilitado. Solo dos de estas pruebas involucran a la IU, y deberían ser tan simples que prácticamente no pueden fallar. Coloque la lógica compleja en el modelo donde se prueba fácilmente.

Answer 5

No probar la interfaz de usuario es, como han dicho otros, un dolor. Me gustaría agregar que la nueva característica Test & Lab Manager de Team Foundation 2010 es una excelente manera de hacer ambas pruebas manuales de UI y automatizando pruebas subsiguientes. Es lo suficientemente inteligente como para reconocer las estructuras de GUI cuando se ejecutan las pruebas, al menos para WinForms, WPF y sitios web.