Redondeando en Java

Si os habéis encontrado alguna vez con la necesidad de redondear un número en Java, habréis visto que no existe un método directo para hacerlo

A veces se hace multiplicando pasando a entero y dividiendo, pero no es una forma fiable.

La forma de hacerlo sería mediante el método setScale de la clase java.math.BigDecimal:

public static double round(double value, int decimalDigits) {
	BigDecimal bd = new BigDecimal(value);
	bd = bd.setScale(decimalDigits, BigDecimal.ROUND_HALF_UP);
	return bd.doubleValue();
}

Tenemos varias opciones a la hora de redondear que podemos ver en la documentación de BigDecimal.

Espero que os ayude.

Error en la comparación de String con la librería de tags de Struts2

Os voy a comentar un pequeño error que nos puede descolocar un poco cuando tratamos de comparar cadenas mediante la librería de etiquetas de Struts2 en nuestras páginas JSP.

Si hacemos una comparación con Strings al estilo de:

<s:if test="propiedad == 'SI'">
  <div>Mostrar texto</div>
</s:if>

obtendremos el resultado esperado (mostrará el texto si nuestra propiedad vale «SI»), pero si la comparación es:

<s:if test="propiedad == 'S'">
 <div>Mostrar texto</div>
</s:if>

veremos que aunque nuestra propiedad valga «S» no aparece el texto. Es decir, que cuando hacemos comparaciones de Strings de un sólo carácter nos falla. La responsable es la librería OGNL que evalúa las expresiones ya que al encontrar se un sólo carácter lo toma como un tipo Char y no un String.

Para solucionarlo nos basta cambiar las comillas:

<s:if test='propiedad == "S"'>
  <div>Mostrar texto</div>
</s:if>

o bien escapar las comillas dobles:

<s:if test="propiedad == \"S\"">
  <div>Mostrar texto</div>
</s:if>

Espero que le pueda servir a alguien.

JUnit: Herramienta indispensable para el desarrollo Java

Hoy voy a hablar de una herramienta que debería ser de uso común para el desarrollo. Estoy hablando de JUnit, la librería de pruebas unitarias más utilizado en entornos Java.

Las pruebas unitarias consisten en desarrollar código para probar una determinada funcionalidad de nuestra aplicación.

Vamos a ver un pequeño ejemplo. Supongamos que estamos haciendo una librería matemática que incluye una funcion para calcular el factorial de un número. Podría ser una clase parecida a la siguiente:

package org.tcymu.util;

public class MathLibrary {
	public static int factorial(int n) throws IllegalArgumentException {
		int response = 1;

		if (n < 0) {
			throw new IllegalArgumentException();
		}

		if (n > 0) {
			response = n * factorial(n - 1);
		}

		return response;
	}
}

En esta entrada voy a utilizar las facilidades que da Eclipse gracias a su integración con JUnit. Para ello en la vista package sobre la clase que queremos probar hacemos botón dereco -> «New» -> «JUnit Test Case».

Nos aparece la siguiente ventana en la que seleccionamos «New JUnit 4 test» (tened en cuenta que JUnit 4 necesita Java 1.5 o superior).

Podemos ver que nos propone un nombre para la clase de pruebas, así como un paquete y una carpeta de fuentes (por defecto propone el mismo paquete que las fuentes, aunque podríamos elegir otro). También podemos seleccionar que nos cree los siguientes métodos de apoyo para preparar el entorno de los test o liberar recursos:

– Métodos setUp y tearDown. Los ejecuta antes de llamar a cada método de prueba en esa clase. La secuencia sería setUp, metodo1Test, tearDown, setUp, metodo2Test, tearDown.

– Métodos setUpBeforeClass y tearDownAfterClass. Estos métodos se ejecutan antes y después de todos los métodos de la clase. La secuencia sería setUpBeforeClass, metodo1Test, metodo2Test, tearDownAfterClass.

A continuación nos pide los métodos que queremos probar. En este ejemplo seleccionamos el método que queremos probar (factorial) y ninguno de los métodos de apoyo (en nuestro sencillo ejemplo no necesitamos crear ni liberar nada).

Tras finalizar y si no tenemos la librería JUnit 4 en el Build Path nos la añade. Y por último crea el esqueleto de la clase de prueba:

package org.tcymu.util;

import static org.junit.Assert.*;

import org.junit.Test;

public class MathLibraryTest {

	@Test
	public void testFactorial() {
		fail("Not yet implemented");
	}

}

Hay que destacar que lo que realmente convierte al método en un test que ejecutará JUnit es la anotación Java @Test, al igual que lo que marcaría a los métodos de apoyo serían anotaciones como @BeforeClass, @AfterClass, @Before y @After.

Podemos observar que el método testFactorial sólo contiene la línea fail("Not yet implemented"); , por lo que si ejecutamos el test (mediante botón derecho sobre la clase de pruebas y «Run As» -> «JUnit Test» se nos abre la vista de JUnit con el siguiente resultado:

Por tanto es hora de implementar nuestra prueba para pasar la barra al ansiado color verde. Básicamente se hacen comprobaciones de los resultados esperados frente a los recibidos mediante la clase org.junit.Assert (documentación Javadoc de JUnit).

package org.tcymu.util;

import static org.junit.Assert.*;

import org.junit.Assert;
import org.junit.Test;

public class MathLibraryTest {

	@Test
	public void testFactorial() {
		Assert.assertEquals(1, MathLibrary.factorial(0));
		Assert.assertTrue(1 == MathLibrary.factorial(1));
		Assert.assertEquals(24, MathLibrary.factorial(4));
		Assert.assertEquals(720, MathLibrary.factorial(6));

		boolean excepcionLanzada = false;
		try {
			MathLibrary.factorial(-1);
		} catch (IllegalArgumentException e) {
			excepcionLanzada = true;
		}
		Assert.assertTrue(excepcionLanzada);
	}

}

Vemos que utilizamos varios métodos para comprobar que se obtiene el resultado esperado. También podemos ver cómo probamos que se lanza la excepción esperada cuando el argumento no es válido (creo haber leído en algún sitio que se iba a mejorar la prueba de excepciones en próximas versiones, pero no consigo localizar la noticia).

Una vez que se ejecutan la prueba con éxito (la barrita verde) sabemos que el método funciona como nosotros esperamos. Ahora tras cualquier cambio en el código volveríamos a ejecutar JUnit para comprobar que no hemos roto nada. Esto nos da una gran seguridad a la hora de meter mano o refactorizar métodos complejos.

Por último no quisiera terminar la entrada sin nombrar un par de temas relacionados con las pruebas unitarias.

– Una buena prueba debe ser repetible (se debe de poder lanzar cuantas veces queramos sin afectar a nada). Por ello cada vez más se automatizan las pruebas en los procesos de integración continua de forma que antes de generarse una versión de una aplicación se corren todas las pruebas para dicha aplicación.

– Existe un modelo de desarrollo que promueve que primero se escriban las pruebas y después el código. Es el llamado Desarrollo Guiado por Pruebas o Test Driven Development (TDD).

Espero que os haya gustado esta pequeña introducción.