Prepara tu Eclipse para TDD con MoreUnit 3

0
4919

En este tutorial vamos a ver un plugin para Eclipse que nos facilita la realización de TDD, supliendo algunas de las características ausentes en este IDE de referencia en Java.

Índice de contenidos

1. Introducción

En el mundo Java se suelen citar tres editores como los más usados dos gratuitos como Eclipse y Netbeans y el todopoderoso (pero de pago) IntelliJ de JetBrains. El más popular por número de usuarios y es Eclipse, lo que no quiere decir que sea el más completo: no es el mejor en el manejo de los test. Quizá se deba a su gran ecosistemas de plugins, gratuitos y de pago, que existen.

Vamos a ver en esta ocasión un plugin sencillo pero fundamental: MoreUnit 3.0.4, que junto con el de cobertura EclEMMA, son parte de mi instalación básica para trabajar con Java como debe hacerse: con especial atención a los test unitario, y si puede ser al TDD.

2. Entorno

Para realizar este tutorial se ha empleado el siguiente entorno de desarrollo:

  • Hardware: Mac Book Pro 15″ Intel Core i7 2,8 GHz, 16 GB RAM.
  • Sistema Operativo: Mac OS X El Capitán.
  • IDE: Eclipse Mars (aunque vale cualquier Eclipse).
  • Plugin: MoreUnit 3.0.4.

No obstante, cualquier máquina en la que ejecutes Eclipse es suficiente.

3. Instalación

Es muy sencillo, como todos los plugins que están en el Eclipse Marketplace: vamos a Help -> Eclipse Marketplace.

Captura de pantalla 2016-02-27 a las 19.40.01

Debería salir una ventana como la siguiente, donde en el control «Find» pondremos MoreUnit para buscarlo:

Captura de pantalla 2016-02-27 a las 19.42.07

… y seguimos los típicos pasos de confirmación de licencia y reinicio de Eclipse para que podamos trabajar con el plugin.

4. ¿Qué nos aporta?

Pues son aportaciones muy sencillas pero que si las hacemos a mano constantemente nos pueden llegar a frustrar y hacer perder bastante tiempo. Mejor que las haga el IDE por nosotros que para eso está.

Nota: Hasta donde he podido comprobar, algunas de ellas ya las incorpora por ejemplo NetBeans, al menos dese la versión 8. Allá vamos:

4.1. Creación automática de clase de test

Esta es por si haces TDD de boquilla… Estando en una clase, pulsamos Ctrl+J y nos aparecerá el diálogo de Eclipse para crear una clase de test. Tendrá el mismo nombre que la clase de código, pero acabada en «Test», como buen test unitario.

Lo bueno es que si estamos en un entorno de tipo maven, done las clases deben estar en src/main/java/packages…/Class.java, nos la crea como src/test/java/packages…/ClassTest.java

Captura de pantalla 2016-02-27 a las 19.52.50

4.2. Creación de clase a partir del test

Pero si haces TDD de verdad, antes de escribir una clase deberás partir de la clase de test y no de la clase a testear. Así, obtendrás un error de compilación a la hora de compilar el test que hace referencia a la clase, y podrás dejar el test en verde creando la clase.

Si usas la funcionalidad de Eclipse para crear la clase: intentará crear la clase en el mismo paquete que test, lo cual es erróneo.

Por ejemplo, si usas maven, el test estará en src/test/java/packages…/UserTest.java e intentará crear la clase ahí, en src/test/java/packages…/User.java cuando en realidad tiene que ir en src/main/java/packages…/User.java.

No te preocupes, pulsa Control+J (o en el menú secundario de MoreUnit->Jump to Class/Test. Te aparecerá un diálogo para crear la nueva clase con el nombre del test, pero quitando «test» y lo hará en el mismo paquete pere en src/main/java. El nombre de la clase será el mismo que el de test pero sin «Test» al final. Es decir de UserTest.java se obtendrá User.java

Captura de pantalla 2016-02-27 a las 19.58.18

4.3. Salto de clase a test y test a clase

Es la que más utilizo sin duda alguna. Sencillo: estás en una clase y quieres ir al test: Ctrl+J. Estás en el test y quieres volver a la clase: Control+J. Se acabó buscar por recursos o tipo en los cientos de clases y test que tienes con Eclipse. Sólo Ctrl+J y permuta entre ambas. Si no estaba el test creado, va al punto anterior.

¿Cómo sabe cuál es la correspondencia entre test y clase? Emplea lo configurado en Eclipse para relacionar nombres de clases y sus test unitarios. Suele ser «Clase.java» -> «ClaseTest.java», es decir, con el sufijo «Test». Si no respetamos esta característica, el plugin no será capaz de encontrarlo.

4.4. Creación de test de método a partir del método

Esto no es TDD, pero ayuda con los test: Si tienes una clase DataProvider y has escrito ya el método o al menos su «signature», como por ejemplo:

public List getUsers(){
		return Arrays.asList(foo);
	}

Con Control+U o «Generate Test Method», se generará el siguiente código en la clase de test correspondiente:

@Test
public void testGetUsers() throws Exception {
	throw new RuntimeException("not yet implemented");
}

Todo listo para desarrollar el test. Fíjate que el nombre del método para testear es «test» + «nombreMétodo».

Seguramente sea más interesante los esquemas de tipo given_when_then o given_should por ejemplo que el de simple testMétodo, pero eso es otra discusión.

4.5. Ejecutar test de la clase

Tanto si estamos en la propia clase de test como si estamos en la clase a testear, pulsando Control+R o «Run Test» en el menú contextual de MoreUnit, ejecutará los test correspondiente. Así no hay que ir a la clase de text y hacer Ctrl+Alt+R+T típico de Eclipse

4.6. Ejecutar test de un método

Tanto si estamos en la clase de test o la clase a testear, si situamos el cursor o seleccionamos un método, podremos ejecutar el test de ese método concreto con Control+Alt+Shift+R o «Run Test of Selected Member».

Esto funcionará siempre que el método de test tenga como nombre «test»+»nombreMétodo». De otro modo no será capaz de encontrarlo… así que nada de given_when_then… 🙁

4.7. Mockear las dependencias de un test

Esta funcionalidad viene bien cuando se hacen test unitarios a posteriori. Cuando una clase tiene una dependencia de otra clase, si estamos hablando de test unitarios, esas dependencias se tienen que hacer a base de mocks, no de objetos reales. De otro modo se trataría de test unitarios. Un buen framework de mocking para Java es Mockito. Otro es PowerMock, pero no recomiendo usarlo:

Volviendo a MoreUnit, si tenemos la clase ya creada y hemos expresado algunas dependencias a base de setters o en constructor, MoreUnit nos propone inicializar estas dependencias con Mocks, evitándonos a nosotros crearlas a mano. Si tenemos la clase:

package com.autentia.moreunit;

public class Front {

	private Service service;
	
	public Front(Service service) {
		super();
		this.service = service;
	}

	public String request(String string) {
		//TODO
		return null;
	}
}

Podemos ver que hay una dependencia con una clase Servicio. Pulsamos Control+J para crear un test para esta clase, que estará en src/test/java/com/autentia/moreunit/FrontTest.java como bien ya sabemos. El contenido inicial será:

package com.autentia.moreunit;

public class FrontTest {

}

Ahora pulsamos: Control+Alt+Shit+M o seleccionamos la acción «Mock dependencies in test case…» y aparecerá un diálogo como el siguiente:

Captura de pantalla 2016-02-27 a las 20.23.41

Aquí podremos elegir el «Mock Style» (elegimos Mockito):

  • EasyMock
  • jMock2
  • JMockit
  • Mockito

… y las características (elegimos without annotations):

  • With annotations
  • With annotations (<Mockito 1.9)
  • Without annotations
  • With PowerMock

Marcamos la dependencia por constructor donde se carga la clase «Servicio» que debe ser mockeada y damos a finish. El resultado es el siguiente código:

package com.autentia.moreunit;

import static org.mockito.Mockito.mock;

import org.junit.Before;

public class FrontTest {
	private Service service = mock(Service.class);
	private Front front;

	@Before
	public void createFront() throws Exception {
		front = new Front(service);
	}

}

Nos ha creado:

  • el Mock de Service sin anotaciones
  • ha incluido las dependencias para Mock
  • e incluso ha instanciado el Subject under test, que es Front
  • y lo ha hecho en el método @Before de JUnit.

No está mal… si esto lo multiplicamos por las veces que lo hacemos a lo largo del día nos salen unos cuantos minutos ahorrados, así como posibles fallos humanos que a veces nos llevan horas depurar 🙂

5. Conclusiones

En este tutorial hemos visto un plugin sencillo que nos hace la vida más cómoda frente a las carencias que trae Eclipse «out of the box». Su instalación y uso es sencillo y su uso continuado a lo largo del día nos ahorra unos valiosos minutos y sobre todo hace que el flujo de la programación basada en test sea más natural, reduciendo el tiempo de búsqueda de clase y creación de operaciones triviales.

DEJA UNA RESPUESTA

Por favor ingrese su comentario!

He leído y acepto la política de privacidad

Por favor ingrese su nombre aquí

Información básica acerca de la protección de datos

  • Responsable:
  • Finalidad:
  • Legitimación:
  • Destinatarios:
  • Derechos:
  • Más información: Puedes ampliar información acerca de la protección de datos en el siguiente enlace:política de privacidad