Pregunta

¿Cuál es la mejor manera de probar el código GWT?

GWTTestCase en modo hospedado es demasiado lento y ninguno de los marcos de simulación funciona.

Actualmente estamos siguiendo MVC como se sugiere en http://robvanmaris.jteam.nl/2008/03/09/test-driven-development-for-gwt-ui-code/ y usando GWTMockUtilities desarmar () y restaurar () para simular widgets . Y no hemos descubierto una manera de probar Vista en GWT MVC. ¿Hay una mejor manera de probar el código GWT?

¿Fue útil?

Solución

Si está buscando probar los widgets de GWT por separado, no hay muchas opciones. Puede usar un GWTTestCase para crear una instancia de sus widgets y probarlos a través de su API, que es lo que Google hace para los propios widgets de GWT: Fuente para RadioButtonTest

Sin embargo, el mecanismo de activación de eventos no funciona en GWTTestCases, lo que significa que no puede hacer cosas como hacer clic en un botón mediante programación y esperar que se invoque algún método de devolución de llamada onClick () en un oyente. También es difícil, si no imposible, obtener el DOM subyacente, por lo que puede que no sea la mejor herramienta para probar código de bajo nivel que emite HTML.

Parece que estás siguiendo todos los pasos correctos; El artículo de Rob proporciona una excelente descripción de cómo escribir código verificable utilizando el patrón de diseño Model-View-Presenter (MVP). Cuanta más lógica mantengas fuera de la capa de vista, mejor. Cuando eso no sea posible, use una herramienta como Selenium para crear pruebas enfocadas del comportamiento dinámico de la IU.

Seguí una estrategia similar: MVP con un código mínimo en los widgets. En algunos casos escribí un código que envolvería la clase Grid, así que pude crear una instancia de mi componente en un GWTTestCase, pasarlo a Grid, invocar algunos métodos en mi componente y verificar el estado de Grid. Escribí un artículo para Better Software sobre Test-First GWT, que puede leer en mi blog .

Si está buscando probar el código que utiliza clases de GWT que no son de la interfaz de usuario (como la codificación de URL o los diccionarios), deberá usar GWTTestCase, o seguir estrategias de ajuste similares hasta que el código sea demasiado sencillo de descifrar. Luego use una prueba de integración con una herramienta como Selenium, o unas pocas GWTTestCases específicas que solo prueben que está usando la biblioteca correctamente, como dice J.B. Rainsberger, "¡No pruebe el marco!" & Quot;

Otros consejos

Como alternativa, debe probar gwt-test-utils , que gestionan la ejecución del código de cliente GWT en una JVM independiente y proporciona alguna característica para simular lo que desee (componente, servicios RPC, etc.)

Lo que funcionó para mí:

Use el modelo / vista / controlador clásico (por ejemplo, no hay lógica de negocios en la vista o el controlador; los controladores solo convierten los eventos de vista en llamadas de método en el modelo).

Desconecte el modelo y el código del controlador de los widgets de visualización de GWT y cualquier otra clase que dependa de GWT y no se pueda crear una instancia en una JVM antigua. Luego puedes probarlos con un buen viejo JUnit.

Escriba pruebas de extremo a extremo para probar el sistema a través de la GUI para asegurarse de que los modelos y controladores estén conectados a las vistas correctamente. Descubrimos que es más rápido implementar e iniciar la aplicación y luego interactuar con ella a través de un navegador controlado desde JUnit con WebDriver que usar GWTTestCase!

Use JMock para probar llamadas asíncronas como esta: http://www.jmock.org/gwt. html .

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