Pues bien, en la super mega clase chachiguay de Entornos de Desarrollo me mandan hacer test con el Junit en Eclipse y esas cosas y comprobar la cobertura con EclEmma. Llevo todo bien, pero éste último ejercicio no lo consigo, bien por dolor de cabeza o porque soy demasiado inútil a éstas horas.
Tengo que conseguir que con el número entero que yo haya establecido en un principio (Ejemplo, 1555), me de su correspondiente en números romanos y comprobar todo el proceso y que pasa por todos los bucles y eso.
Sin más dilación aquí os dejo el código a ver si alguien me pudiera ayudar.
GRACIAS!
/**
* @return una cadena representando el número en números romanos
*/
public String toRomano() {
String numRomano = "";
//Obtenemos cada cifra del número
int miles = numero / 1000;
int centenas = numero / 100 % 10;
int decenas = numero / 10 % 10;
int unidades = numero % 10;
//Unidades de millar
for (int i = 1; i <= miles; i++) {
numRomano = numRomano + "M";
}
//Centenas
if (centenas == 9) {
numRomano = numRomano + "CM";
} else if (centenas >= 5) {
numRomano = numRomano + "D";
for (int i = 6; i <= centenas; i++) {
numRomano = numRomano + "C";
}
} else if (centenas == 4) {
numRomano = numRomano + "CD";
} else {
for (int i = 1; i <= centenas; i++) {
numRomano = numRomano + "C";
}
}
//Decenas
if (decenas == 9) {
numRomano = numRomano + "XC";
} else if (decenas >= 5) {
numRomano = numRomano + "L";
for (int i = 6; i <= decenas; i++) {
numRomano = numRomano + "X";
}
} else if (decenas == 4) {
numRomano = numRomano + "XL";
} else {
for (int i = 1; i <= decenas; i++) {
numRomano = numRomano + "X";
}
}
//Unidades
if (unidades == 9) {
numRomano = numRomano + "IX";
} else if (unidades >= 5) {
numRomano = numRomano + "V";
for (int i = 6; i <= unidades; i++) {
numRomano = numRomano + "I";
}
} else if (unidades == 4) {
numRomano = numRomano + "IV";
} else {
for (int i = 1; i <= unidades; i++) {
numRomano = numRomano + "I";
}
}
return numRomano;
}
}
Pues en principio creo que con hacer un test para cada caso. Algo así como:
public class numRomanoTest{
@Test
public void testNumRomanos(){
Assert.assertEquals("Los numeros no coinciden","CMLXIV", toRomano(964));
Assert.assertEquals("Los numeros no coinciden","CDXXV", toRomano(425));
...
}
y Así para cada condicion. Pillate una pagina con un conversor para hacer las pruebas.
Lo que debes hacer es pruebas para que pase por todas las condiciones de los ifs.
Por ejemplo:
if (centenas == 9) {
numRomano = numRomano + "CM";
} else if (centenas >= 5) {
numRomano = numRomano + "D";
for (int i = 6; i <= centenas; i++) {
numRomano = numRomano + "C";
}
} else if (centenas == 4) {
numRomano = numRomano + "CD";
} else {
for (int i = 1; i <= centenas; i++) {
numRomano = numRomano + "C";
}
}
Ahí tendrás que usar un test con las centenas a 9, entre 8 y 5, a 4 y menores de 3.
Por ejemplo: 900, 700, 400 y 300.
De esta forma nos aseguramos que pase por las 4 posibles opciones para las centenas.
Habrá que repetir el proceso con decenas y unidades.
Otra opción es buscar números que comprueben varios a la vez, como el 999, 567, 444, 123, con esos cuatro números comprobaríamos todos las opciones de los if’s.
Vale, investigando y probando cosas resulta que es más sencillo de lo que parece (quién lo iba a decir). Aquí os pongo la solución para que le echéis un vistazo ^^
Si has prendido a usar el debugger (que tristemente no suelen enseñarlo en las asignaturas de programación) una forma para saber si pasa por todas las condiciones es poner un breakpoint en cada uno y conforme va a saltando cada breakpoint lo quitas. Si cuando terminas todos los tests has quitado todos, pues es que has pasado por todos
Es buena técnica, pero usando herramientas de cobertura puede obtener una representación gráfica después de una ejecución normal. Parece que lo cubren en el curso, así que fenómeno.
A la solución yo anyadiría los “imprevistos”: qué pasa si metemos un 0? y un número negativo? Hay errores o devuelve un resultado esperado? Hay alguna manera de llamar a toRomano() sin establecer un valor inicial?
El orden correcto es “assertEquals(“CCXIII”, numero.toRomano())”. Si miráis el javadoc de assertEquals, lo primero que se le pasa es el resultado esperado. De no hacerlo así, los mensajes de error pueden ser muy confusos.
También es buena idear dividir las comprobaciones en tests unitarios individuales, para que si revienta un assert no deje de comprobar el resto de condiciones.
Escribir buenos tests unitarios es engorroso y lleva tiempo, pero vale mucho la pena.
No sé si va al tema pero puede ayudar.
Hoy en packt Publishing regalan el libro “Test-Driven Java Development” (lo pongo como viene en la página, respetando mayúsculas)
Desgraciadamente quitan el libro cada 24 horas. Afortunadamente ponen uno nuevo cada 24 horas. Es cuestión de seguir un poco el tema y te haces de una colección bastante buena