Unit Tests (II): clases sin interfaz

Sigamos con los tests unitarios: ¿qué ocurre si alguna de mis dependencias no tiene interfaz? O simplemente, ¿qué ocurre si no me gusta añadir una interfaz a cada una de mis clases?

Aunque recomiendo encarecidamente el uso de interfaces (ayudan a definir y delimitar el alcance de una clase), no es del todo extraño que algunas de nuestras dependencias no las tengan. Como ejemplo, veamos una que seguro que a muchos nos ha tocado implementar: un cliente para leer los mensajes de Twitter. Si decidimos usar el proyecto Twitter4J, nos encontramos con que su cliente twitter4j.Twitter no tiene interfaz.

Si intentáramos hacer un test usando la guía del post anterior:

    [...]
    private TwitterService twitterService = null;

    private Mockery mockery = new Mockery();
    private Twitter twitterMock = null;

    @Before
    public void setUp() {
        twitterService = new TwitterService();

        twitterMock = mockery.mock(Twitter.class);
        twitterService.setTwitter(twitterMock);
    }
    [...]

nos lanzaría la siguiente excepción:

java.lang.IllegalArgumentException: twitter4j.Twitter is not an interface
    at java.lang.reflect.Proxy.getProxyClass(Proxy.java:362)
    at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:581)
    at org.jmock.lib.JavaReflectionImposteriser.imposterise(JavaReflectionImposteriser.java:31)
    at org.jmock.Mockery.mock(Mockery.java:139)
    at org.jmock.Mockery.mock(Mockery.java:120)
    [...]

Por suerte, JMock ha pensado en nosotros (JMock Cookbook, capítulo 18) y nos permite definir Expectations sobre una clase o clase abstracta, dejando a un lado la API estándar de Reflection de Java y modificando/reescribiendo el bytecode en tiempo de ejecución. Entonces, ¿qué hay que hacer para conseguir hacer mock de una clase sin interfaz?

En primer lugar, hay que añadir las siguientes bibliotecas a nuestro classpath:

• jmock-legacy (la misma versión que JMock. En este caso la 2.5.1 aunque funciona con toda la rama 2.x).
• cglib-nodep (probado con la versión 2.2, funciona con todas las 2.x).
• objenesis (probado con la versión 1.2, funciona con todas las 1.x).
  

Y en segundo lugar, modificar la creación del objeto Mockery del siguiente modo:

[...]
import org.jmock.Mockery;
import org.jmock.Expectations;
import org.jmock.lib.legacy.ClassImposteriser;
[...]

public class TwitterServiceTest {

    private TwitterService twitterService = null;

    private Mockery mockery = new Mockery() {
        {
            setImposteriser(ClassImposteriser.INSTANCE);
        }
    };

    private Twitter twitterMock = null;

    @Before
    public void setUp() {
        twitterService = new TwitterService();

        twitterMock = mockery.mock(Twitter.class);
        twitterService.setTwitter(twitterMock);
    }
    [...]

Como podéis ver, sólo cambia el modo de instanciar el objeto Mockery. Para inicializar los mock-objects de nuestras dependencias, se sigue utilizando el mismo método: context.mock(twitter4j.Twitter.class);. Del mismo modo la definición de Expectations de cada test sigue funcionando igual (recibir un mensaje, una excepción, enviar una actualización, ...):

    @Test
    public void testGetMessages() throws Exception {
        mockery.checking(new Expectations() {
            {
                List<Object> statuses = new ArrayList<Object>();
                for (int i = 0; i < 10; i++) {
                    statuses.add(new Object());
                }
                exactly(1).of(twitterMock).getUserTimeline();
                will(returnValue(statuses));
            }
        });

        List<Status> result = twitterService.getMessages();
        assertNotNull(result);
        assertEquals(10, result.size());
    }

Justamente esta clase Twitter forma parte de las dependencias difíciles de integrar en nuestros tests. Parece que intenten ir en contra de cada uno de los consejos para conseguir código testable (http://misko.hevery.com/code-reviewers-guide/). Por ejemplo, el hecho de añadir lógica y excepciones en sus constructores nos hace muy complicado poder crear un objeto twitter4j.Status, ya que necesita una cadena JSON bastante complicada... De todos modos, como estamos probando una clase nuestra que tiene la dependencia con el cliente Twitter, nos interesa ver cómo se comporta ante cada una de las situaciones esperadas (excepciones de conexión, de autorización, resultados nulos, etc). Dependiendo de lo queramos implementar, sólo un pequeño número de tests necesitarán probar respuestas concretas (p.ej., qué ocurre cuando se recibe una fecha incorrecta o un campo vacío). Si queremos probar casos concretos de respuesta, siempre se puede crear una cadena JSON completa, de ejemplo, y utilizarla para crear las distintas instancias de twitter4j.Status que necesitemos dentro de las Expectations. Con estos resultados "simulados" ya podremos ver cómo se comporta nuestra implementación en (casi) todas las situaciones posibles.