Dos Ideas. - Contribuciones del usuario [es]

Tests De JUnit Parametrizados

2010-05-05T20:30:41Z

Marianocifre: Parámetros - Tipos de datos

Hay situaciones en las que debemos correr un tests varias veces pero con diferente juego de datos. Para estos casos [[JUnit]] tiene el Runner ''org.junit.runners.Parameterized'' que permite que escribamos el caso de test separado del juego de datos.

Los tipos de datos soportados por el momento son String o variables primitivas (eg: int, char, etc)

==Ejemplo==

Supongamos el test de una clase que convierte un número de una base en otra. En lugar de escribir varios métodos @Test, se escribe un sólo método @Test que JUnit correrá con cada juego de datos.

Clase a testear:

<code>
public class Calculadora {
...
public static String calcular(String numero, int baseOrigen, int baseDestino) {
...
//calcula el resultado
return resultado;
}
</code>

Valores que se eligen para el test:

{| cellspacing="1" cellpadding="1" border="1" style="width: 313px; height: 124px;"
|-
| Número 
| Base Origen 
| Base Destino 
| Salida 
|-
| 10 
| 2 
| 10 
| 2 
|-
| 255 
| 10 
| 16 
| FF 
|-
| AB 
| 16 
| 10 
| 171 
|-
| 255 
| 10 
| 2 
| 11111111 
|}

 

Este sería el test

<code java="java">
import static org.junit.Assert.assertEquals;

import java.util.Arrays;
import java.util.Collection;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class CalculadoraSecuenciaTest {

private String numero;
private int baseOrigen;
private int baseDestino;
private String resultado;

@Parameters
public static Collection<Object[]> data() {
Object[][] data = {
//Numero BaseOrigen BaseDestino Resultado
{ "10", 2, 10, "2" },
{ "255", 10, 16, "FF" },
{ "AB", 16, 10, "171" },
{ "255", 10, 2, "11111111" }
};
return Arrays.asList(data);
}

public CalculadoraSecuenciaTest(
String numero, int baseOrigen, int baseDestino, String resultado) {

this.numero = numero;
this.baseOrigen = baseOrigen;
this.baseDestino = baseDestino;
this.resultado = resultado;
}

@Test
public void calcular_conNumeroYBases_retornaResultado() {
String resultadoObtenido = Calculadora.calcular(numero, baseOrigen, baseDestino);
assertEquals(resultado, resultadoObtenido);
}
}
</code>

=== Como funciona ===

#Se indica a JUnit que utilice el Runner Parameterized con la anotación @RunWith.
##Con este Runner JUnit instanciará la clase de test tantas veces como juego de datos tenga.
#Se define un constructor que recibe los parametros de cada juego de datos.
##Cada vez que el Runner instancia la clase le pasa un nuevo juego de datos por el constructor.
#Se define un metodo con la anotación @Parameters (Por convención lo llamamos "data").
##En este método creamos una matriz en donde cada fila representa a un juego de datos.
##Se debe respetar el orden de columnas con la definición del constructor.
##La matriz se devuelve como una List de Object[].
#Por último, se crea el metodo marcado como @Test.
##Este método se ejecutará una vez por cada juego de datos.
##Es posible definir más de un método @Test.

== Ver también ==
*[[JUnit]]
*[http://junit.org/apidocs/index.html?org/junit/runners/Parameterized.html Javadoc oficial de la clase Parameterized]
*[http://www.dosideas.com/java/743-test-secuencial-con-selenium-y-junit.html Test Secuancial con Selenium y JUnit]
*[[TwiP]]

[[Category: JUnit]]

Prueba Unitaria

2010-05-03T13:09:19Z

Marianocifre: Link a Prueba De Integracion

Una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con la [[Prueba De Integracion]], se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto. Esto último es la esencia de una prueba unitaria: se prueba al componente de forma aislada a todos los demás.

Para funcionar, un test unitario no debería utilizar ningún framework de aplicación ni requerir una dependencia externa: ni Spring, ni Struts, ni una base de datos, ni un application server, ni un EJB deployado, ni ningún otro servicio cualquiera funcionando.

Así, el testeo unitario se encarga de probar el funcionamiento aislado de la clase. Todas las dependencias que tenga la clase bajo test deberían ser simuladas usando distintos [[Mock Object]].

==Características==
Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:

* Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para [[Integracion Continua]].
* Completas: deben cubrir la mayor cantidad de código.
* Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para [[Integracion Continua]].
* Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
* Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

Aunque estos requisitos no tienen que ser cumplidos a rajatabla, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.

==Ver también==
* [[Herramientas Para Pruebas Unitarias]]
* [[Automatizacion De Pruebas Unitarias]]
* [[Test Driven Development]]
* [[Mock Object]]
* [[Spring Test]]
* [[Testing De Aplicaciones]]
* [http://es.wikipedia.org/wiki/Prueba_unitaria Prueba unitaria en la Wikipedia]
* [http://www.theserverside.com/tt/articles/article.tss?l=DesigntoUnitTest Design to unit test]

[[Category:TDD]]

Interrupciones En Scrum

2010-04-10T16:37:32Z

Marianocifre: Corrección menor

[[Category:Scrum]]
El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[Scrum Master]] es el responsable de quitar estos impedimientos del camino, de manera de no afectar la velocidad del equipo.

Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su [[Sprint]], tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el [[Dueño Del Producto]]. De hecho, de poco le servirá al [[Dueño Del Producto]] que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.

===Tipos de interrupciones===

Durante el proceso de [[Scrum]] pueden surgir diferentes tipos de interrupciones, que atentan contra la entrega de software para el [[Sprint]] en curso. Estas interrupciones puede ser:
* Soporte técnico que no puede ser resuelto por la primer línea de soporte de la empresa
* Tareas de mantenimiento del sistema.
* Pedidos de investigación de comportamientos extraños en el sistema.
* Pedidos de información del sistema que no se consiguen facilmente, y requieren la dedicación de un desarrollador.
* Problemas en el entorno productivo (por ejemplo, mala performance o caidas) que requieren la atención de desarrolladores.

==Gestión de interrupciones==

Todos estos aspectos (y algunos más) puede ser potencialmente más importantes que completar nuevas historias. Entonces, ¿cómo manejar estas interrupciones en el [[Sprint]]?

Hay varias formas de llevar adelante las interrupciones, y depende de la cultura de la empresa y las características de la propia interrupción.

*'''Usar dos Backlog''': tener un backlog para las características del producto, y otro para temas relacionados al soporte de producción. El [[Dueño Del Producto]] define la cantidad de trabajo que se realiza en cada backlog. En este escenario, se puede llevar un gráfico burn-down para el backlog del producto, y un gráfico burn-up para el soporte a producción.

*'''Bugs como historias''': se ubican las interrupciones como historias dentro del backlog del producto, y se estiman de la misma manera, incluso los problemas productivos. El [[Dueño Del Producto]] luego las prioriza según sus necesidades, y elige acorde.

*'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint.

====Atención de las interrupciones====
Otro tema importante a resolver es quién deberá trabajar en las interrupciones. El soporte de producción puede ser aburrido, y en general nadie del equipo quiere hacerlo. Es por esto que tener un equipo dedicado al soporte no es buena idea. Además, un equipo dedicado a soporte genera una división de las tareas, con la confusión que esto trae.

Una opción es contar con un "rol de soporte" que vaya cambiando de Sprint a Sprint, o semanalmente. Esto ayuda a reforzar el sentido de equipo, y como beneficio adicional aumenta el conocimiento general del sistema.

Otra opción para atender las interrupciones es utilizar el concepto de "Sacrificar una persona". con este concepto, la solución del problema se asigna a una persona que se dedica en forma exclusiva a la interrupción. Si bien esta persona queda "sacrificada", el resto del equipo puede seguir progresando en su actividad principal.

En resumen, cuando llegue el momento de gestionar interrupciones, considerar el ubicarlas en el backlog del producto, y priorizarlas. Esto ayuda a asegurarse de que el equipo siempre esté realizando el trabajo correcto. De todas formas, si la interrupción es una emergencia, entonces ocurrirá un costo para el Sprint, y la decisión dependerá de evaluar este costo versus una resolución inmediata.

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]
* [http://www.infoq.com/news/2008/07/interruption-driven-development Interruption Driver Development]