Testeando GUIs

Llevo tiempo convencido de que el mismo código, dependiendo de cómo se haga, puede ser fácil de testear o imposible. Un comentario de Roberto M. Oliva y un ojo a su blog "The Gold Bug" y en concreto a un post de "mas sobre MVC" me han llevado a dos artículos interesantes que vienen a reafirmarme en mi idea inicial.

Las interfaces de usuario son esas cosas que tradicionalmente son difíciles de testear. En ese par de artículos proponen dos formas de hacerlas, basadas en MVC en el que la parte que queda sin testear se hace lo más pequeña posible o, al menos, el código que queda sin testear es código básico en el que se vea rápido si está mal, código sin demasiados riesgos de fallo.

Uno de ellos es Supervising Controller, En este "patrón" se deja en el controlador la lógica más compleja de la vista. A la vista se le deja su funcionalidad más simple y toda la complicación se lleva al controlador. De esta forma, como el controlador es más fácil de testear que la vista, podemos realizar el test de esa funcionalidad compleja. Además, si es necesario, un pequeño "mock object"(1) de la vista nos puede ayudar a testear el controlador.

El otro es Passive View. En este patrón la vista es totalmente tonta y estúpida. No ve ni siquiera al modelo de datos. El controlador es el encargado de hacerlo todo. Cuando el usuario pulsa algo en la GUI, se entera el controlador. Este hace absolutamente todo y luego le dice a la vista qué tiene que mostrar. Nuevamente el test del controlador debería ser más fácil que el de la vista y nuevamente podríamos apoyarnos en mock objects de la vista.

Está mal decirlo, pero estoy deseando que llegue el Lunes para hacer algo de esto en el trabajo… ¡¡Lástima que me espere un estúpido documento word para hacer!!

(1) mock object. Si tenemos que testear una clase A que usa una clase B -en este caso el controlador usa la vista-, podemos reemplazar la clase B por otra con la misma interface y hecha a nuestra medida para el test. Esta clase a medida es un "mock object" que reemplaza a B y nos ayuda a testear a A, ya que podemos enterarnos a qué métodos de B llama y con qué valores, ayudándonos a decidir si A realiza bien su trabajo.

Entradas relacionadas:

  • No hay entradas relacionadas.

2 comentarios en “Testeando GUIs

  1. ¿Y qué opinas sobre testear las propias GUIs en si mismas? [1][2]. Yo hasta que alguien me convenza opino que es perdida de tiempo testear la propia GUI (se testea su lógica!).

    Como bien has comentado en este post, hay que programar facilitando luego el testeo. El caso de las GUIs es de los casos más extremos donde, si no se piensa bien, luego puede ser prácticamente imposible testear

    [1] http://abbot.sourceforge.net/doc/overview.shtml
    [2] http://www.marathontesting.com/

  2. Hola:

    Había oido hablar de herramientas, si no esas mismas, sí como esas. Fíjate que JUnit es más o menos un estándar. Hay otras menos conocidas, pero la que más se usa es JUnit. Sin embargo, para testear GUIs hay muchas y ninguna es un estándar.

    Para mi eso es significativo. Quiere decir que las GUIs son realmente difíciles de testear y que no hay herramientas que claramente ayuden a ello, como para convertirse en estándar.

    Creo que la mejor opción es hacer alguno de los patrones que menciono en el post -o algo similar- de forma que en la GUI sólo quede código lo más trivial posible y así poder NO testearla con cierta seguridad.

    Se bueno.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.