#powermock

Mockito Introduction Part – 1

Recently I have come across a Mockito mocking framework for writing unit test cases. I found it simple to use and have written test cases for my android project. Finally decided to share information, let me start with what is need to start writing unit test cases in Android via Mockito. There will be two parts of the series where in first article I will be giving an introduction to the framework…

Mockito – c’est un library open source pour simplifier les tests unitaires (Unit testing), qui utilise les objets « mock » qui simulent le comportement d'objets réels de manière contrôlée. Pour commencer, il faut telecharger le framework d’ici : http://mockito.org/ Autrement ajouter ce block dans votre XML Maven. <dependency>  <groupId>org.mockito</groupId>  <artifactId>mockito-core</artifactId>  <version>RELEASE</version>  <scope>test</scope> </dependency>

Le class utilisé plus suivant est le class org.mockito.Mockito . Pour tester n’import quel class, utilisez le command mock(class). Apres il faut utiliser when(mock).thenReturn(valeur). Si vous indiquez plus que 1 valeur de retour, la fonction   va les retourner un après autre jusqu’à la fin.  P.e.

import static org.mockito.Mockito.*; import static org.junit.Assert.*; import java.util.Iterator; import org.junit.Test; ....    @Test    public void iterator_will_return_hello_world() {        //Préparation        Iterator i = mock(Iterator.class);        when(i.next()).thenReturn("Hello").thenReturn("World");        //Exécution        String result = i.next()+" "+i.next();        //Comparaison        assertEquals("Hello World", result);    }

On simule la création d’un itérateur et le retour de « hello «  avec la 1re itération et « world » pour les itérations subséquents. Les valeurs qui sont retournés peuvent être utilisés, p.e,  dans un « assert ». Dans le cas d’un iterateur , le méthode « next » n’utilise pas des arguments. Mais on peut aussi tester un méthode avec les arguments. Si un argument ne peut pas être spécifié au moment de test, on peut utiliser anyInt ou anyString(), p.e. pour « mocker » le class « Comparable » : @Test    public void with_unspecified_arguments() {        Comparable c = mock(Comparable.class);        when(c.compareTo(anyInt())).thenReturn(-1);        assertEquals(-1, c.compareTo(5));    }

Va retourner -1 pour n’importe quel argument. Avec les méthodes qui retournent « void » , on ne peut pas utiliser « when() », on utilise doReturn(result).when(mock_object).void_method_call() ; Aussi on pourrait utiliser .thenThrow() ou doThrow() pour les voids.

@Test(expected=IOException.class)    public void OutputStreamWriter_rethrows_an_exception_from_OutputStream()            throws IOException {        OutputStream mock = mock(OutputStream.class);        OutputStreamWriter osw = new OutputStreamWriter(mock);        doThrow(new IOException()).when(mock).close();        osw.close();    }

So I was trying out mocking frameworks for the first time a few days ago, and there’s an interesting observation: even though EasyMock, PowerMock, and Mockito and said to be brothers-in-arms, there are a few nuances to take care of. One of them is the following.

There are convenience methods (called matchers) provided by both Mockito and EasyMock to define a message signature that can accept anyv…

Hace ya un mes, para complementar mi charla en la PyConEs 2.013, escribí una entrada sobre cómo podemos aislarnos de las dependencias del sistema utilizando dobles de prueba (enlace).

En el último dojo de código del año (el #IWT2 DojoUs que celebramos cada mes o mes y medio en Sevilla), hemos utilizado ese mismo ejemplo para aprender a utilizar dobles de prueba con Java y Mockito. Todo el código de esta entrada está disponible en GitHub.

A continuación incluyo un resumen de lo que hemos hecho.

El problema.

Tenemos un servicio cualquiera con un método y otra clase distinta que decide si llamar a ese método o no en función de la fecha. En concreto, lo llamará si el día es par y no lo llamará si es impar. Veamos como probarlo.

Una idea de la solución

La información que la prueba necesita controlar es la fecha, y, en concreto el día. El resultado que la prueba evaluará para ver si se ejecutó con éxito o no es ver si el método del servicio fue llamado o no. Para esto necesitamos un doble de prueba que reemplace al servicio. 

  Interfaz que implementa el servicio. No necesitaremos ninguna implementación en ste ejemplo porque usaremos un spy creado con Mockito.

En este caso lo creamos con Mockito, como se muestra en el código que aparece más abajo.

¿Cómo controlamos que la fecha que la clase bajo prueba obtiene es par o impar? Veamos tres estrategias distintas.

  Primera estrategia, pasar la fecha como parámetro.

Con esta estrategia, la clase bajo prueba no recupera ella misma la fecha del sistema, sino que lo hace quien la llama y se la pasa como parámetro. Así, podemos controlar la fecha creando un objeto de la clase java.util.Calendar e indicándole un día concreto.

Esta estrategia (pruebas e implementación) se muestran en el siguiente código.

Segunda estrategia, encapsular la obtención de la fecha.

  Con esta estrategia creamos un nuevo servicio que será el responsable de devolver la fecha actual del sistema. A la clase bajo prueba le pasamos un stub (hecho también con Mockito) que devuelva la fecha que nos interesa.

Esta estrategia (pruebas e implementación) se muestra en el siguiente código.

  Tercera estrategia, reemplazar la llamada al sistema.

  Con esta estrategia la clase bajo pruebas llama directamente al sistema para obtener la fecha actual, pero con PowerMock interceptamos dicha llamada para que devuelva la fecha que necesita la prueba.

  Esta estrategia (pruebas e implementación) se muestra en el siguiente código.

Conclusiones:

Es difícil seleccionar la mejor estrategia de las tres vistas en un ejemplo con tan pocos detalles. Muchas vece serán estos detalles los que nos harán decantarnos por una solución u otra.

De manera general, no suele ser aconsejable utilizar demasiado herramientas como PowerMock, por lo que abusar de ellas puede ser un mal olor que nos indique que tenemos u diseño demasiado acoplado, difícil de modificar y de depurar.

    No te vayas… aún hay más

Otros enlaces sobre temas de dobles y pruebas que puedes encontrar en este mismo blog son:

Cómo aislarnos de las dependencias del sistema. Un caso práctico con Python, MagicMock y TDD 

Mocks en Python

Kata Tenis en Python paso a paso aplicando TDD

Test-Driven Development Práctico. Algoritmo de la Criba de Eratóstenes.

Proyecto Android Testing Snippets

Enlaces:

Desarrollo dirigido por pruebas en Python (I): Una historia que pasa todos los días

Mockito

메뉴얼 한글화 - 감사합니다.

http://blog.naver.com/PostView.nhn?blogId=kjs077&logNo=10137344512

1. 사용법 정리

http://javacan.tistory.com/entry/MocktestUsingMockito

2. jUnit 을 이용한 효과적 단위테스트 전략

http://www.javajigi.net/pages/viewpage.action?pageId=278

3. JUnitPerf - 부하테스트

http://bcho.tistory.com/112

http://socurites.com/m/post/view/id/24

4. powermock

https://code.google.com/p/powermock/wiki/MockitoUsage13

5. powermockito private method verify

http://code.google.com/p/powermock/wiki/MockitoUsage13

       <dependency>             <groupId>junit</groupId>             <artifactId>junit</artifactId>             <version>4.10</version>             <scope>test</scope>         </dependency>

        <dependency>             <groupId>org.mockito</groupId>             <artifactId>mockito-all</artifactId>             <version>1.9.0</version>             <scope>test</scope>         </dependency>

        <dependency>             <groupId>org.powermock</groupId>             <artifactId>powermock-core</artifactId>             <version>1.4.12</version>             <scope>test</scope>         </dependency>

        <dependency>             <groupId>org.powermock</groupId>             <artifactId>powermock-module-junit4</artifactId>             <version>1.4.12</version>             <scope>test</scope>         </dependency>

        <dependency>             <groupId>org.powermock</groupId>             <artifactId>powermock-api-mockito</artifactId>             <version>1.4.12</version>             <scope>test</scope>         </dependency>

http://code.google.com/p/powermock/source/browse/trunk/modules/module-test/easymock/junit4-test/src/test/java/samples/junit4/expectnew/ExpectNewDemoTest.java

http://code.google.com/p/powermock/wiki/MockConstructor

https://groups.google.com/forum/#!topic/powermock/M3WAfA_eDZA

http://code.google.com/p/powermock/wiki/MockConstructor