Dos Ideas. - Contribuciones del usuario [es]

HSQLDB

2012-05-23T14:32:52Z

Uva:

[[Categoría: Base De Datos]]
[[Categoría: Java]]

HSQLDB es una [[Base De Datos]] creada completamente en [[Java]], liviana y rápida.

== Problemas con la hora de la JVM ==

===Objetivo===
Obtener la fecha del sistema en un script de HSQLDB.

===Contexto===
* Script HSQLDB en test de componentes.
* Versión de jdk inferior a 1.7.0_04

===Problema===

* Al momento de utilizar la función '''sysdate''' para obtener la fecha del sistema desde el script, el resultado que obteníamos no era el esperado. la fecha que retornaba correspondía al día siguiente al que teníamos configurado en la pc.

* Mirando con mayor detenimiento, pudimos constatar que esto nos sucedía para todas las funciones similares (CURRENT_DATE,TODAY, NOW, etc)

* Usando las funciones CURRENT_TIME y CURRENT_TIMESTAMP vimos que en realidad lo que estaba sucediendo es que había una diferencia de +15 horas con la real de la pc.

* Esto se debía a que la jvm tomaba por default el huso horario de Asia/Magadan.

===Solución===

* Instalamos la última versión de la jdk disponible en la web (jdk1.7.0_04)
* Nos aseguramos que el huso horario configurado en la pc sea "Buenos Aires/Georgetown"

== Ver también ==
* [http://www.hsqldb.org/ Web oficial de HSQLDB ]

Archivo:EjemploGuavaComparacionListas.gif

2012-05-23T14:26:04Z

Uva:

Ejemplo con Google Guava Comparator

2012-05-23T14:25:01Z

Uva: Página creada con '=Objetivo= * Encontrar una manera de organizar listas de una determinada entidad, por un conjunto de campos específico, de manera de poder tener múltiples criterios de ordena…'

=Objetivo=

* Encontrar una manera de organizar listas de una determinada entidad, por un conjunto de campos específico, de manera de poder tener múltiples criterios de ordenamiento sobre la misma clase.

=Situación ejemplo=

* Tenemos una clase Tarea
* Tarea está asociada a un Usuario
* Tarea tiene una fecha.
* Usuario tiene dos String que representan el nombre y apellido respectivamente.

[[Archivo:EjemploGuavaComparacionListas.gif]]

* Tenemos que ordenar una '''List<Tarea>''' , por apellido y nombre del usuario relacionado, y fecha de la tarea.

==SIN Guava==

* Deberíamos crear una clase '''TareaComparator''' que implemente '''Comparator<Tarea>''',
poniendo en el siguiente método:

@Override
public int compare(Tarea t1, Tarea t2) {
//código armando el criterio de ordenamiento de cada tarea
//aca se deberia armar/concatenar todos los criterios en uno solo, obteniendo tareaCriterio1 y tareaCriterio2
return tareaCriterio1.compareTo(tareaCriterio2);
}

* Luego en nuestro código de negocio, al momento de ordenar deberíamos invocar a Collections.sort(lista, tareaComparator)

* De dicha manera, si quisiéramos tener otro criterio de ordenamiento, deberíamos tener una clase por cada criterio distinto de ordenamiento.

==CON librerías de [[http://code.google.com/p/guava-libraries/| Guava ]] ==

* Crear la clase '''TareaComparator''', sin implementar ninguna interfaz.

/**
* Constructor privado.
*/
private TareaComparator() {
}
/**
* Ordena tarea por nombre de usuario.
*/
private static Comparator<Tarea> byNombre = new Comparator<Tarea>() {
@Override
public int compare(final Tarea p1, final Tarea p2) {
return p1.getUsuario().getNombre().compareTo(p2.getUsuario().getNombre());
}
};
/**
* Ordena tarea por apellido de usuario.
*/
private static Comparator<Tarea> byApellido = new Comparator<Tarea>() {
@Override
public int compare(final Tarea p1, final Tarea p2) {
return p1.getUsuario().getApellido().compareTo(p2.getUsuario().getApellido());
}
};
/**
* Ordena tarea por fecha.
*/
private static Comparator<Tarea> byFecha = new Comparator<Tarea>() {
@Override
public int compare(final Tarea p1, final Tarea p2) {
return p1.getFecha().compareTo(p2.getFecha());
}
};
/**
* @return byNombre
*/
public static Comparator<Tarea> getByNombre() {
return byNombre;
}
/**
* @return byApellido
*/
public static Comparator<Tarea> getByApellido() {
return byApellido;
}
/**
* @return byFecha
*/
public static Comparator<Tarea> getByFecha() {
return byFecha;
}

* Luego en nuestro código de negocio, al momento de ordenar deberíamos usar:

List<Tarea> tareasOrdenadas = Ordering.from(TareaComparator.getByApellido())
.compound(TareaComparator.getByNombre())
.compound(TareaComparator.getByFecha())
.sortedCopy(tareasDesordenadas);

* De esta manera, podemos anidar criterios de ordenamiento, combinándolos de las maneras que necesitemos, teniendo las comparaciones agrupadas en una sola clase.

[[Category:Java]]

Google Guava

2012-05-23T14:23:36Z

Uva: /* Ver también */

[http://code.google.com/p/guava-libraries/ Google Guava] es un proyecto de Google que reúne un conjunto de librerías usadas internamente dentro de Google para sus proyectos que emplean Java. El propósito de la librería es simplificar el código empleado para realizar tareas que son comunes dentro de [[Java]] y que no están soportadas por las librerías estándar, de esta manera busca eliminar código propenso a errores.

== Maven ==

<code xml>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>r09</version>
</dependency>
</code>

Controlara última versión [http://mvnrepository.com/artifact/com.google.guava/guava aquí].

== Ejemplos ==

===CharMatcher===

Determina verdadero o falso para cualquier carácter java, también ofrece métodos básicos de tratamiento de texto.

==== and / or ====

<code java>
String input = "La fecha es : 01/01/2011";
CharMatcher charMatcher = CharMatcher.DIGIT.or(CharMatcher.is('/'));
String output = charMatcher.retainFrom(input);
System.out.println(output);

// Salida : 01/01/2011
</code>

==== negate ====

<code java>
String input = "MAYUSCULA minuscula";
CharMatcher charMatcher = CharMatcher.JAVA_LOWER_CASE.or(CharMatcher.WHITESPACE).negate();
String output = charMatcher.retainFrom(input);
System.out.println(output);

// Salida: MAYUSCULA
</code>

==== inRange ====

<code java>
String input = "Solo quedan los numeros 1, 2, 3, 4 que son menores a 5 ";
CharMatcher charMatcher = CharMatcher.inRange('0', '4').or(CharMatcher.WHITESPACE);
String output = charMatcher.retainFrom(input);
System.out.println(output);

// Salida: 1 2 3 4
</code>

=== Joiner ===

Une fragmentos de texto mediante un separador. también ofrece métodos básicos de tratamiento de texto.

==== join ====

<code java>
String[] nombres = {"Josefina", "Nacho", "Lali", "Coco"};
String output = Joiner.on(", ").join(nombres);
System.out.println(output);

// Salida: Josefina, Nacho, Lali, Coco
</code>

==== skipNulls ====

<code java>
String[] nombres = {null, "Josefina", null, "Nacho", null, "Lali", null, "Coco"};
String output = Joiner.on(", ").skipNulls().join(nombres);
System.out.println(output);

// Salida: Josefina, Nacho, Lali, Coco
</code>

==== useForNull ====

<code java>
String[] nombres = {null, "Josefina", null, "Nacho", null, "Lali", null, "Coco"};
String output = Joiner.on(", ").useForNull("n/a").join(nombres);
System.out.println(output);

// Salida: n/a, Josefina, n/a, Nacho, n/a, Lali, n/a, Coco
</code>

==== withKeyValueSeparator ====

<code java>
Map<Integer, String> map = newHashMap();
map.put(1, "Josefina");
map.put(2, "Nacho");
map.put(3, "Lali");
String output = Joiner.on(", ").withKeyValueSeparator(" -> ").join(map);
System.out.println(output);

// Salida: 1 -> Josefina, 2 -> Nacho, 3 -> Lali
</code>

=== Splitter ===

Divide cadenas de texto en subcadenas mediante el reconocimiento de un separador (también conocido como delimitador), este se puede definir mediante un carácter, una cadena literal, una expresión regular, un CharMatcher, o mediante el uso de una longitud fija.

==== split ====

Split retorna una instancia de Iterable en lugar de un Array.

<code java>
String input = "Josefina|Nacho|Lali";
Iterable<String> split = Splitter.on("|").split(input);
List<String> output = newArrayList(split);
System.out.println(output);

// Salida: [Josefina, Nacho, Lali]
</code>

==== fixedLength ====

<code java>
String input ="Josefina Nacho Lali ";
Iterable<String> splitted = Splitter.fixedLength(10).trimResults().split(input);
List<String> output = newArrayList(splitted);
System.out.println(output);

//Salida: [Josefina, Nacho, Lali]
</code>

==== onPattern ====

<code java>
String input ="Josefina Nacho Lali";
Iterable<String> splitted =
Splitter.onPattern("[a-z&&[aeiou]]").omitEmptyStrings().split(input);
List<String> output = newArrayList(splitted);
System.out.println(output);

// Salida: [J, s, f, n, N, ch, L, l]
</code>

=== Collection2 ===

Proporciona métodos estáticos para trabajar con colecciones.

==== filter ====

<code java>
List<String> input = newArrayList("Josefina","Nacho","Lali");
Collection<String> output =
Collections2.filter(input, new Predicate<String>() {

public boolean apply(String t) {
if (t.contains("i")) {
return true;
}
return false;
}
});

System.out.println(output);

// Salida: [Josefina, Lali]
</code>

==== transform ====

<code java>
List<String> input = newArrayList("Josefina", "Nacho", "Lali");
Collection<String> output =
Collections2.transform(input, new Function<String, String>() {

public String apply(String f) {
return f.replaceAll("fina","");
}
});

System.out.println(output);

// Salida: [Jose, Nacho, Lali]
</code>

=== Constraints ===

Restringe la carga de las colecciones medinate limitaciones.

==== constrainedCollection ====

<code java>
Constraint<String> debeContenerJoL = new Constraint<String>() {

@Override
public String checkElement(String s) {
checkNotNull(s);
if (!s.contentEquals("JL")) {
throw new IllegalArgumentException("No contiene J ni L");
}
return s;
}
};

Collection<String> input = newArrayList("Josefina");
Collection<String> output = constrainedCollection(input, debeContenerJoL);
output.add("Nacho");

// Salida:
Exception in thread "main" java.lang.IllegalArgumentException: No contiene J ni L
</code>

<code java>
Collection<String> input = newArrayList("Josefina");
Collection<String> output = constrainedCollection(input, notNull());
output.add(null);

// Salida:
Exception in thread "main" java.lang.NullPointerException
</code>

=== Ordering ===

Comparador con métodos para soportar funciones comunes.

==== sortedCopy ====

<code java>
List<String> input = newArrayList("Josefina","Nacho","Lali");

Ordering<String> ordering = Ordering.from(new Comparator< String>() {

@Override
public int compare(String string1, String string2) {
return Ints.compare(string1.length(), string2.length());

}
});

List<String> output = ordering.sortedCopy(input);
System.out.println(output);

// Salida: [Lali, Nacho, Josefina]
</code>

=== Multimap ===

Basicamente es un map en el que se pueden asignar muchos valores a una sola clave.

<code java>
Multimap<Integer, String> output = HashMultimap.create();
output.put(1, "Josefina");
output.put(2, "nacho");
output.put(3, "Lali");
output.put(1, "Josefina_2");
System.out.println(output);

// Salida: {1=[Josefina, Josefina_2], 2=[Bacho], 3=[lali]}
</code>

==== ImmutableSetMultimap ====

===== inline =====
<code java>
Multimap<Integer, String> output =
ImmutableSetMultimap.of(1, "Josefina", 2, "Nacho", 3, "Lali", 1, "Josefina_2");
System.out.println(output);

// Salida: {1=[Josefina, Josefina_2], 2=[Nacho], 3=[Lali]}
</code>

===== builder =====

<code java>
Multimap<Integer, String> output =
new ImmutableSetMultimap.Builder<Integer, String>()
.put(1, "Josefina")
.put(2, "Nacho")
.put(3, "Lali")
.put(1, "Josefina_2")
.build();
System.out.println(output);

// Salida: {1=[Josefina, Josefina_2], 2=[Bacho], 3=[Lali]}
</code>

=== Tables ===

Es una colección con columnas filas y valores. Permite el traspaso de una tabla a otra.

<code java>
Table<Integer, String, String> table = HashBasedTable.create();
table.put(1, "Hija", "Josefina");
table.put(1, "Sobrino", "Nacho");
table.put(1, "Pareja", "Lali");

Table output = Tables.transpose(table);

System.out.println(output);

// Salida: {Sobrino={1=Nacho}, Hija={1=Josefina}, Pareja={1=Lali}}
</code>

=== BiMap ===

Es un Map que solo permite valores únicos.

<code java>
BiMap<Integer, String> output = HashBiMap.create();
output.put(1, "Josefina");
output.put(2, "Lali");
output.put(3, "Josefina"); //IllegalArgumentException

// Salida:
Exception in thread "main" java.lang.IllegalArgumentException: value already present: Josefina

</code>

=== Throwables ===

Clase utilitaria que contiene métodos estáticos para el manejo de excepciones.

==== propagate ====

En el caso de que la excepción sea del tipo RuntimeException la lanza, de lo contrario crea una RuntimeException con la excepción recibida y la lanza.

<code java>
try {
throw new Exception("Error !!!");
} catch (Throwable t) {
throw Throwables.propagate(t);
}

// Salida:
Exception in thread "main" java.lang.RuntimeException: java.lang.Exception: Error !!!
at com.google.common.base.Throwables.propagate(Throwables.java:155)
at com.dosideas.guavalibrarydemo.Ejemplo.main(Ejemplo.java:92)
Caused by: java.lang.Exception: Error !!!
at com.dosideas.guavalibrarydemo.Ejemplo.main(Ejemplo.java:90)
</code>

=== Files ===

Clase con métodos útiles para el manejo de archovs.

==== readLines ====

<code java>
ClassLoader cla = App.class.getClassLoader();
File file = new File(cla.getResource("prueba.txt").getFile());
List<String> lines = Files.readLines(file, Charsets.UTF_8);
</code>

==Ver también==
* [[Ejemplo con Google Guava Comparator]]
* [http://code.google.com/p/dosideas-aplicaciones-modelo/source/browse/#svn Descargar con svn de nuestro proyecto en google-code la aplicación demo de Google Guava]
* [http://www.javacodegeeks.com/2011/09/google-guava-libraries-essentials.html Google Guava Libraries Essentials]
* [http://guava-libraries.googlecode.com/svn/tags/release09/javadoc/index.html Google Guava API]

[[Category:Java]]

Prueba De Integracion Dummy con Ant

2011-11-15T21:08:51Z

Uva:

En diferentes oportunidades nos surge la necesidad de realizar pruebas de Integración contra servidores o servicios que no están disponibles por X motivo.

Este es un ejemplo de solución para un servicio que consume un Conector, el cuál le pega a una plataforma que no está disponible. Utilizando una clase Mock y un poco de ant, podemos generar un distribuible que nos sirva para probar el servicio de manera Mock.

== Contexto ==

Supongamos que tenemos un servicio que estamos exponiendo, que internamente se comunica con un conector mediante una librería cliente. Lo hace mediante este Dao

<code java5="java5">
@Repository
public class ConectorDaoImpl implements ConectorDao {

/**
* Conector delegate.
*/
@Autowired
private ConnectorRemoteBusiness conector;

/**
* @{@inheritDoc}.
*/
@Override
public void llamarAConector(String parametro) {
// código...
}

}
</code>

Ahora supongamos que para nuestros test de componentes nos generemos una implementación mock del cliente del conector, para manejar datos dummy para nuestras pruebas:

<code java5="java5">

public class ConnectorRemoteBusinessMock implements ConnectorRemoteBusiness {

@Override
public String invocarConector(String parametro) throws RemoteException {
String respuesta = null;

switch (parametro) {
case 1: respuesta = "Respuesa1" break;
case 2: respuesta = "Respuesa2" break;
case 3: respuesta = "Respuesa3" break;
default: respuesta = "default"; break;
}
return respuesta;
}

}

</code>

Y en los test de componentes, configuramos Spring para que al Dao se le inyecte la implementación Mock.

Ahora, supongamos que nuestro servidor sigue caído, y necesitamos generar un distribuible que utilice este Dao con la inyección del delegate mock. Podemos tunear las tareas ant para realizar dicha acción. Ahora vamos a ver como.

== Generando el Distribuible Mock ==

La estructura del proyecto es la siguiente en este ejemplo:

/src/java/com...    Código del empaquetado

/test/com/....       Paquete de la clase Mock 

/test/componentes/com... Código de los test de componentes. 

Vamos a generar una tarea ant a la cual llamaremos "dist-mock" que tendrá por salida un war con un Dao que utiliza una interface Mock del Cliente del conector. Para esto necesitamos copiar no solo la clase mock, sino el archivo de Spring para inyectarle este mock al dao. Y luego limpiar la clase mock de nuestro src. Veamos el código ant en un build.xml: 

<code xml="xml">

<target name="dist-mock">
<echo>Dist Mock</echo>
<property name="esMock" value="true" />
<property name="claseMock"
value="./test/componente/com/.../ConnectorRemoteBusinessMock.java" />
<property name="directorioDestino"
value="./src/java/com/.../ejb" />
<property name="ejb-xml-mock"
value="./test/componente/spring-ejb-Componente.xml" />
<ant target="dist" inheritall="true" />
</target>

<target name="-pre-compile" if="esMock">
<echo>Pre compile Mock</echo>
<copy file="${claseMock}" todir="${directorioDestino}" />
</target>

<target name="-post-compile" if="esMock">
<echo>Post compile Mock</echo>
<copy file="${ejb-xml-mock}" todir="${build.classes.dir}" />
<move file="${build.classes.dir}/spring-ejb-Componente.xml"
tofile="${build.classes.dir}/spring-ejb.xml" />
</target>

<target name="-post-dist" if="esMock">
<echo>Post dist Mock</echo>
<delete dir="./src/java/com/tm" />
</target>

</code>

Ahora expliquemos un poco cada parte del ant. 

#Primero, ejecutando la tarea dist-mock estamos diciendo explicitamente que queremos un distribuible mock. Esto es recomendado, ya que de sobrescribir la tarea dist, podemos olvidarnos y migrar cosas dummy. En la tarea dist-mock se setea en true una variable "esMock". Despues nos guardamos un par de propiedades por simplicidad del código, y llamamos a la tarea dist. 
#En el pre-compile estamos ubicados antes de que ant compile las clases. Este es el momento en donde copiamos la clase mock a nuestro src.
#En el post-compile, las clases ya estan compiladas, y llevamos nuestro archivo de componentes de spring a donde quedaron las clases compiladas, y lo renombramos para pisar el archivo spring de src
#Luego, en el post-dist, antes de terminar, limpiamos el src y borramos la clase mock que copiamos

Con esto tenemos un distribuible mock para hacer nuestras pruebas de "pseudo integración", que pueden servirnos para avanzar con un desarrollo. Igual recuerden, que hasta no integrar nuestro código con los servicios reales, no deberíamos dar como terminado el mismo! Cuando antes fallemos en nuestro desarrollo, mas tiempo tendremos de resolver nuestros problemas.

Prueba De Integracion Dummy con Ant

2011-11-15T21:06:22Z

Uva:

En diferentes oportunidades nos surge la necesidad de realizar pruebas de Integración contra servidores o servicios que no están disponibles por X motivo.

Este es un ejemplo de solución para un servicio que consume un Conector, el cuál le pega a una plataforma que no está disponible. Utilizando una clase Mock y un poco de ant, podemos generar un distribuible que nos sirva para probar el servicio de manera Mock.

== Contexto ==

Supongamos que tenemos un servicio que estamos exponiendo, que internamente se comunica con un conector mediante una librería cliente. Lo hace mediante este Dao

<code java5="java5">
@Repository
public class ConectorDaoImpl implements ConectorDao {

/**
* Conector delegate.
*/
@Autowired
private ConnectorRemoteBusiness conector;

/**
* @{@inheritDoc}.
*/
@Override
public void llamarAConector(String parametro) {
// código...
}

}
</code>

Ahora supongamos que para nuestros test de componentes nos generemos una implementación mock del cliente del conector, para manejar datos dummy para nuestras pruebas:

<code java5="java5">

public class ConnectorRemoteBusinessMock implements ConnectorRemoteBusiness {

@Override
public String invocarConector(String parametro) throws RemoteException {
String respuesta = null;

switch (parametro) {
case 1: respuesta = "Respuesa1" break;
case 2: respuesta = "Respuesa2" break;
case 3: respuesta = "Respuesa3" break;
default: respuesta = "default"; break;
}
return respuesta;
}

}

</code>

Y en los test de componentes, configuramos Spring para que al Dao se le inyecte la implementación Mock.

Ahora, supongamos que nuestro servidor sigue caído, y necesitamos generar un distribuible que utilice este Dao con la inyección del delegate mock. Podemos tunear las tareas ant para realizar dicha acción. Ahora vamos a ver como.

== Generando el Distribuible Mock ==

La estructura del proyecto es la siguiente en este ejemplo:

/src/java/com...    Código del empaquetado

/test/com/....       Paquete de la clase Mock 

/test/componentes/com... Código de los test de componentes. 

 

Vamos a generar una tarea ant a la cual llamaremos "dist-mock" que tendrá por salida un war con un Dao que utiliza una interface Mock del Cliente del conector. Para esto necesitamos copiar no solo la clase mock, sino el archivo de Spring para inyectarle este mock al dao. Y luego limpiar la clase mock de nuestro src. Veamos el código ant en un build.xml: 

<code xml="xml">

<target name="dist-mock">
<echo>Dist Mock</echo>
<property name="esMock" value="true" />
<property name="claseMock"
value="./test/componente/com/.../ConnectorRemoteBusinessMock.java" />
<property name="directorioDestino"
value="./src/java/com/.../ejb" />
<property name="ejb-xml-mock"
value="./test/componente/spring-ejb-Componente.xml" />
<ant target="dist" inheritall="true" />
</target>

<target name="-pre-compile" if="esMock">
<echo>Pre compile Mock</echo>
<copy file="${claseMock}" todir="${directorioDestino}" />
</target>

<target name="-post-compile" if="esMock">
<echo>Post compile Mock</echo>
<copy file="${ejb-xml-mock}" todir="${build.classes.dir}" />
<move file="${build.classes.dir}/spring-ejb-Componente.xml"
tofile="${build.classes.dir}/spring-ejb.xml" />
</target>

<target name="-post-dist" if="esMock">
<echo>Post dist Mock</echo>
<delete dir="./src/java/com/tm" />
</target>

</code>

Ahora expliquemos un poco cada parte del ant. 

#Primero, ejecutando la tarea dist-mock estamos diciendo explicitamente que queremos un distribuible mock. Esto es recomendado, ya que de sobrescribir la tarea dist, podemos olvidarnos y migrar cosas dummy. En la tarea dist-mock se setea en true una variable "esMock". Despues nos guardamos un par de propiedades por simplicidad del código, y llamamos a la tarea dist. 
#En el pre-compile estamos ubicados antes de que ant compile las clases. Este es el momento en donde copiamos la clase mock a nuestro src.
#En el post-compile, las clases ya estan compiladas, y llevamos nuestro archivo de componentes de spring a donde quedaron las clases compiladas, y lo renombramos para pisar el archivo spring de src
#Luego, en el post-dist, antes de terminar, limpiamos el src y borramos la clase mock que copiamos

Con esto tenemos un distribuible mock para hacer nuestras pruebas de "pseudo integración", que pueden servirnos para avanzar con un desarrollo. Igual recuerden, que hasta no integrar nuestro código con los servicios reales, no deberíamos dar como terminado el mismo! Cuando antes fallemos en nuestro desarrollo, mas tiempo tendremos de resolver nuestros problemas.

Prueba De Integracion Dummy con Ant

2011-11-15T20:47:45Z

Uva: Página creada con 'En diferentes oportunidades nos surge la necesidad de realizar pruebas de Integración contra servidores o servicios que no están disponibles por X motivo. Este es un ejemplo…'

Prueba De Integracion

2011-11-15T20:09:18Z

Uva: Página creada con 'Estrategias de Testeo de aplicaciones a nivel Integración * Prueba De Integracion Dummy con Ant'

Estrategias de Testeo de aplicaciones a nivel Integración

* [[Prueba De Integracion Dummy con Ant]]

Selenium con DSL

2011-04-26T18:54:48Z

Uva: /* Ejemplo */

[[Selenium]] es una herramienta para pruebas de aplicaciones web. Quién tuvo la posibilidad de utilizarla, sabrá lo poderosa que es la herramienta, la cuál tiene diversas funciones para ejecutar con nuestra aplicación web.
Puede ocurrir, que nuestros test de [[Selenium]] se vayan complejizando a medida que nuestra aplicación crece, por lo que esta es una posible solución, combinando el poder de [[Selenium]] con un enfoque [[DSL]].

== Ejemplo ==

A continuación mostramos una propuesta de como encarar un test de [[Selenium]] con [[DSL]]. Para el ejemplo, suponemos una aplicación con seguridad, usuarios con diferentes Roles, y diferentes pantallas:

=== AltaDenunciaSeleniumTest ===
<code java>
package com.test;

import static org.junit.Assert.fail;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

import com.test.selenium.dsl.Usuario;

public class AltaDenunciaSeleniumTest {

@BeforeClass
public static void setUpClass() throws Exception {
Usuario.inicializar();
}

@AfterClass
public static void tearDownClass() throws Exception {
Usuario.finalizar();
}

@Test
public void ingresarConRolAdministrativo_SeDaDeAltaUnaDenuncia() {
Usuario.ingresarComoAdministrativo()
.irAingresarDenuncia()
.completarDenuncia()
.aceptar()
.verificarFinalizacionSinErrores()
.salir();
}
}

</code>

De esta forma, escribimos el test de manera que al leer los métodos a los que se invoca, se entiende paso a paso lo que el test realiza, sin confundirnos con la implementación. Utilizando los patrones “method chaining” y “builder” la implementación de la clase Usuario sería una cosa así:

=== Usuario ===
<code java>
package com.test.selenium.dsl;

import org.openqa.selenium.server.SeleniumServer;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;
import com.test.selenium.dsl.pagina.HomeAdministrativo;

public class Usuario {

public static final String TIEMPO_ESPERA = "90000";
public static final String VELOCIDAD_CERO = "0";
public static final String VELOCIDAD_TEST = "350";

private static SeleniumServer seleniumServer;
private static Selenium selenium ;

public static void inicializar() throws Exception {
seleniumServer = new SeleniumServer();
seleniumServer.start();
selenium = new DefaultSelenium( "localhost", 4444, "*chrome", "http://localhost:8585/");
selenium.start();
}

public static HomeAdministrativo ingresarComoAdministrativo() {
Usuario.login("administrativo");
return new HomeAdministrativo(selenium);
}

public static void finalizar() {
selenium.stop();
seleniumServer.stop();
}

private static void login(String username) {
selenium.setSpeed(VELOCIDAD_TEST);
selenium.open("");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
if (selenium.isElementPresent("relogin")) {
selenium.click("relogin");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
}
selenium.type("username", username);
selenium.click("submitbutton");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
selenium.setSpeed(VELOCIDAD_CERO);

}

}

</code>

Como vemos en el ejemplo, el método ingresarComoAdministrativo instancia y devuelve un objeto de la clase HomeAdministrativo cuya implementación es:

=== HomeAdministrativo ===
<code java>
package com.test.selenium.dsl.pagina;

import static org.junit.Assert.assertEquals;

import com.thoughtworks.selenium.Selenium;
import com.test.selenium.dsl.Usuario;

public class HomeAdministrativo {

private Selenium selenium;

public HomeAdministrativo(Selenium selenium) {
this.selenium = selenium;
}

public AltaDenuncia irAingresarDenuncia() {
selenium.setSpeed(Usuario.VELOCIDAD_TEST);
selenium.getEval("this.browserbot.getCurrentWindow().selectview('applications')");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
selenium.click("link=IngresarDenuncia");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
selenium.setSpeed(Usuario.VELOCIDAD_CERO);
return new AltaDenuncia(selenium);
}

public void salir() {
selenium.setSpeed(Usuario.VELOCIDAD_TEST);
selenium.getEval("this.browserbot.getCurrentWindow().logoutMethod()");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
if (selenium.isElementPresent("submit")) {
selenium.click("submit");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
}
selenium.setSpeed(Usuario.VELOCIDAD_CERO);
}

public HomeAdministrativo verificarFinalizacionSinErrores() {
assertEquals("IngresarDenuncia", selenium.getText("link=IngresarDenuncia"));
return this;
}

}

</code>

Volvemos a utilizar el patrón builder y el método ingresar denuncia devuelve un objeto de la clase AltaDenuncia. De esta manera, cada clase representa a una pantalla de la aplicación, y expone cada funcionalidad que la misma ofrece. AltaDenuncia sería así:

=== AltaDenuncia ===
<code java>
package com.test.selenium.dsl.pagina;

import com.thoughtworks.selenium.Selenium;
import com.test.selenium.dsl.Usuario;

public class AltaDenuncia {

private Selenium selenium;

public AltaDenuncia(Selenium selenium) {
this.selenium = selenium;
}

public AltaDenuncia completarDenuncia() {

// Acá iría el código Selenium para completar los campos

return this;
}

public HomeAdministrativo aceptar() {

selenium.click("OK");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);

return new HomeAdministrativo(selenium);
}

public HomeAdministrativo cancelar() {
selenium.click("CANCELAR");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);

return new HomeAdministrativo(selenium);
}

}

</code>

Tanto el cancelar como el aceptar, devuelven la pantalla anterior. Todo se maneja con objetos que representan cada pantalla.

== Conclusiones ==

El resultado de hacer los test de esta manera, es la facilidad de escritura y mantenimiento del test en si mismo. A su vez, se podría diseñar las clases a utilizar en el DSL a conveniencia.

Selenium con DSL

2011-04-26T18:52:36Z

Uva: /* Ejemplo */

[[Selenium]] es una herramienta para pruebas de aplicaciones web. Quién tuvo la posibilidad de utilizarla, sabrá lo poderosa que es la herramienta, la cuál tiene diversas funciones para ejecutar con nuestra aplicación web.
Puede ocurrir, que nuestros test de [[Selenium]] se vayan complejizando a medida que nuestra aplicación crece, por lo que esta es una posible solución, combinando el poder de [[Selenium]] con un enfoque [[DSL]].

== Ejemplo ==

A continuación mostramos una propuesta de como encarar un test de [[Selenium]] con [[DSL]]. Para el ejemplo, suponemos una aplicación con seguridad, usuarios con diferentes Roles, y diferentes pantallas:

<code java>
package com.test;

import static org.junit.Assert.fail;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

import com.test.selenium.dsl.Usuario;

public class AltaDenunciaSeleniumTest {

@BeforeClass
public static void setUpClass() throws Exception {
Usuario.inicializar();
}

@AfterClass
public static void tearDownClass() throws Exception {
Usuario.finalizar();
}

@Test
public void ingresarConRolAdministrativo_SeDaDeAltaUnaDenuncia() {
Usuario.ingresarComoAdministrativo()
.irAingresarDenuncia()
.completarDenuncia()
.aceptar()
.verificarFinalizacionSinErrores()
.salir();
}
}

</code>

De esta forma, escribimos el test de manera que al leer los métodos a los que se invoca, se entiende paso a paso lo que el test realiza, sin confundirnos con la implementación. Utilizando los patrones “method chaining” y “builder” la implementación de la clase Usuario sería una cosa así:

<code java>
package com.test.selenium.dsl;

import org.openqa.selenium.server.SeleniumServer;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;
import com.test.selenium.dsl.pagina.HomeAdministrativo;

public class Usuario {

public static final String TIEMPO_ESPERA = "90000";
public static final String VELOCIDAD_CERO = "0";
public static final String VELOCIDAD_TEST = "350";

private static SeleniumServer seleniumServer;
private static Selenium selenium ;

public static void inicializar() throws Exception {
seleniumServer = new SeleniumServer();
seleniumServer.start();
selenium = new DefaultSelenium( "localhost", 4444, "*chrome", "http://localhost:8585/");
selenium.start();
}

public static HomeAdministrativo ingresarComoAdministrativo() {
Usuario.login("administrativo");
return new HomeAdministrativo(selenium);
}

public static void finalizar() {
selenium.stop();
seleniumServer.stop();
}

private static void login(String username) {
selenium.setSpeed(VELOCIDAD_TEST);
selenium.open("");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
if (selenium.isElementPresent("relogin")) {
selenium.click("relogin");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
}
selenium.type("username", username);
selenium.click("submitbutton");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
selenium.setSpeed(VELOCIDAD_CERO);

}

}

</code>

Como vemos en el ejemplo, el método ingresarComoAdministrativo instancia y devuelve un objeto de la clase HomeAdministrativo cuya implementación es:

<code java>
package com.test.selenium.dsl.pagina;

import static org.junit.Assert.assertEquals;

import com.thoughtworks.selenium.Selenium;
import com.test.selenium.dsl.Usuario;

public class HomeAdministrativo {

private Selenium selenium;

public HomeAdministrativo(Selenium selenium) {
this.selenium = selenium;
}

public AltaDenuncia irAingresarDenuncia() {
selenium.setSpeed(Usuario.VELOCIDAD_TEST);
selenium.getEval("this.browserbot.getCurrentWindow().selectview('applications')");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
selenium.click("link=IngresarDenuncia");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
selenium.setSpeed(Usuario.VELOCIDAD_CERO);
return new AltaDenuncia(selenium);
}

public void salir() {
selenium.setSpeed(Usuario.VELOCIDAD_TEST);
selenium.getEval("this.browserbot.getCurrentWindow().logoutMethod()");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
if (selenium.isElementPresent("submit")) {
selenium.click("submit");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
}
selenium.setSpeed(Usuario.VELOCIDAD_CERO);
}

public HomeAdministrativo verificarFinalizacionSinErrores() {
assertEquals("IngresarDenuncia", selenium.getText("link=IngresarDenuncia"));
return this;
}

}

</code>

Volvemos a utilizar el patrón builder y el método ingresar denuncia devuelve un objeto de la clase AltaDenuncia. De esta manera, cada clase representa a una pantalla de la aplicación, y expone cada funcionalidad que la misma ofrece. AltaDenuncia sería así:

<code java>
package com.test.selenium.dsl.pagina;

import com.thoughtworks.selenium.Selenium;
import com.test.selenium.dsl.Usuario;

public class AltaDenuncia {

private Selenium selenium;

public AltaDenuncia(Selenium selenium) {
this.selenium = selenium;
}

public AltaDenuncia completarDenuncia() {

// Acá iría el código Selenium para completar los campos

return this;
}

public HomeAdministrativo aceptar() {

selenium.click("OK");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);

return new HomeAdministrativo(selenium);
}

public HomeAdministrativo cancelar() {
selenium.click("CANCELAR");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);

return new HomeAdministrativo(selenium);
}

}

</code>

Selenium con DSL

2011-04-26T18:49:43Z

Uva: /* Ejemplo */

[[Selenium]] es una herramienta para pruebas de aplicaciones web. Quién tuvo la posibilidad de utilizarla, sabrá lo poderosa que es la herramienta, la cuál tiene diversas funciones para ejecutar con nuestra aplicación web.
Puede ocurrir, que nuestros test de [[Selenium]] se vayan complejizando a medida que nuestra aplicación crece, por lo que esta es una posible solución, combinando el poder de [[Selenium]] con un enfoque [[DSL]].

== Ejemplo ==

A continuación mostramos una propuesta de como encarar un test de [[Selenium]] con [[DSL]]. Para el ejemplo, suponemos una aplicación con seguridad, usuarios con diferentes Roles, y diferentes pantallas:

<code java>
package com.test;

import static org.junit.Assert.fail;

import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

import com.test.selenium.dsl.Usuario;

public class AltaDenunciaSeleniumTest {

@BeforeClass
public static void setUpClass() throws Exception {
Usuario.inicializar();
}

@AfterClass
public static void tearDownClass() throws Exception {
Usuario.finalizar();
}

@Test
public void ingresarConRolAdministrativo_SeDaDeAltaUnaDenuncia() {
Usuario.ingresarComoAdministrativo()
.irAingresarDenuncia()
.completarDenuncia()
.aceptar()
.verificarFinalizacionSinErrores()
.salir();
}
}

</code>

De esta forma, escribimos el test de manera que al leer los métodos a los que se invoca, se entiende paso a paso lo que el test realiza, sin confundirnos con la implementación. Utilizando los patrones “method chaining” y “builder” la implementación de la clase Usuario sería una cosa así:

<code java>
package com.test.selenium.dsl;

import org.openqa.selenium.server.SeleniumServer;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;
import com.test.selenium.dsl.pagina.HomeAdministrativo;

public class Usuario {

public static final String TIEMPO_ESPERA = "90000";
public static final String VELOCIDAD_CERO = "0";
public static final String VELOCIDAD_TEST = "350";

private static SeleniumServer seleniumServer;
private static Selenium selenium ;

public static void inicializar() throws Exception {
seleniumServer = new SeleniumServer();
seleniumServer.start();
selenium = new DefaultSelenium( "localhost", 4444, "*chrome", "http://localhost:8585/");
selenium.start();
}

public static HomeAdministrativo ingresarComoAdministrativo() {
Usuario.login("administrativo");
return new HomeAdministrativo(selenium);
}

public static void finalizar() {
selenium.stop();
seleniumServer.stop();
}

private static void login(String username) {
selenium.setSpeed(VELOCIDAD_TEST);
selenium.open("");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
if (selenium.isElementPresent("relogin")) {
selenium.click("relogin");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
}
selenium.type("username", username);
selenium.click("submitbutton");
selenium.waitForPageToLoad(TIEMPO_ESPERA);
selenium.setSpeed(VELOCIDAD_CERO);

}

}

</code>

Como vemos en el ejemplo, el método ingresarComoAdministrativo instancia y devuelve un objeto de la clase HomeAdministrativo cuya implementación es:

<code java>
package com.test.selenium.dsl.pagina;

import static org.junit.Assert.assertEquals;

import com.thoughtworks.selenium.Selenium;
import com.test.selenium.dsl.Usuario;

public class HomeAdministrativo {

private Selenium selenium;

public HomeAdministrativo(Selenium selenium) {
this.selenium = selenium;
}

public AltaDenuncia irAingresarDenuncia() {
selenium.setSpeed(Usuario.VELOCIDAD_TEST);
selenium.getEval("this.browserbot.getCurrentWindow().selectview('applications')");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
selenium.click("link=IngresarDenuncia");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
selenium.setSpeed(Usuario.VELOCIDAD_CERO);
return new AltaDenuncia(selenium);
}

public void salir() {
selenium.setSpeed(Usuario.VELOCIDAD_TEST);
selenium.getEval("this.browserbot.getCurrentWindow().logoutMethod()");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
if (selenium.isElementPresent("submit")) {
selenium.click("submit");
selenium.waitForPageToLoad(Usuario.TIEMPO_ESPERA);
}
selenium.setSpeed(Usuario.VELOCIDAD_CERO);
}

public HomeAdministrativo verificarFinalizacionSinErrores() {
assertEquals("IngresarDenuncia", selenium.getText("link=IngresarDenuncia"));
return this;
}

}

</code>

Selenium con DSL

2011-04-26T18:47:47Z

Uva: /* Ejemplo */

Selenium con DSL

2011-04-26T18:45:23Z

Uva:

Selenium con DSL

2011-04-26T18:41:04Z

Uva: /* Ejemplo */

Selenium con DSL

2011-04-26T18:40:35Z

Uva: /* Ejemplo */

Selenium con DSL

2011-04-26T18:39:39Z

Uva:

Selenium con DSL

2011-04-26T18:26:25Z

Uva: Página creada con 'Selenium es una herramienta para pruebas de aplicaciones web. Quién tuvo la posibilidad de utilizarla, sabrá lo poderosa que es la herramienta, la cuál tiene diversas fun…'

DSL

2011-04-26T18:23:51Z

Uva:

''Fuente: [http://eamodeorubio.wordpress.com/2010/09/13/%C2%BFque-son-los-dsl-domain-specific-languages/ Que son los Dsl]''

== Qué son los DSL ==

DSL (Domain Specific Languages) se llama a cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas. Se diferencian de los lenguajes de programación, que están pensados para resolver cualquier tipo de problemas (lenguajes generalistas). Estos últimos, lo que suman en generalidad, también lo hacen en complejidad.

De esta forma nació el enfoque de los DSL, en vez de usar un lenguaje generalista, puedo usar diversos lenguajes de propósito específico, para resolver los diferentes problemas que surgen al implementar una aplicación. Por lo tanto sería muy eficiente contar con varios DSL, uno para cada tipo de problema con el que nos solemos encontrar, y para los problemas no tan típicos (los menos) solucionarlos con lenguajes generalistas.

Se utilizan DSL para resolver por ejemplo:
* Definición de interfaces de usuario
* Seguridad.
* Transacciones.
* Persistencia.
* Validación.
* Definición de tests automatizados

Ejemplos de DSL:
* SQL
* XML
* HTML
* CSS
* JSP

Existe un ciclo de vida en la evolución de una solución a un problema dentro del software. Primero resolvemos el problema como se nos ocurra. Después, conforme ganamos experiencia, al resolver el problema varias veces en contextos distintos, encontramos buenas prácticas o “recetas”, que nos permiten resolver el problema mediante copy/paste. En una etapa posterior de maduración, conseguimos abstraer esas recetas, en una librería que sigue un determinado diseño, y obtenemos un patrón de diseño al abstraer el diseño de la implementación en si. Una vez que tenemos varios patrones de diseño que resuelven distintos problemas de la misma categoría, podemos implementarlos juntos, y obtenemos un framework. Finalmente, y este es el paso menos conocido, el framework se hace cada vez más configurable y automatizado, con lo que éste termina evolucionando en un DSL.

== Tipos de DSL ==
Desde el punto de vista del tipo de problemas que resuelven, tenemos dos tipos de DSL, DSLs de negocio y DSLs técnicos. Sin embargo existe otra forma diferente de categorizar los DSLs, según el enfoque a la hora de implementarlos. De esta manera tenemos dos tipos:

=== DSLs externos ===
Un DSL externo es un lenguaje en si mismo, independiente de cualquier otro lenguaje. Posee su propia sintaxis, compilador y/o interprete, e incluso puede llegar a tener su propio IDE. Ejemplos de DSLs externos son SQL o ANTLR.
Los DSLs externos son el típico caso en el que uno piensa cuando se imagina un DSL, un lenguaje nuevo y aparte de los que ya existen.

=== DSLs internos ===
En este enfoque no construimos un lenguaje desde cero, sino que aprovechamos un lenguaje ya existente para construir nuestro DSL. Usando un poco de imaginación y exprimiendo los trucos del lenguaje anfitrión y su sintaxis, podemos construir una librería o framework que implemente el DSL de forma nativa al lenguaje anfitrión. Algunas técnicas usadas son los patrones “method chaining” y “builder”, el uso de métodos factoría estáticos, import estáticos, tipos y métodos paramétricos (genéricos) y por supuesto mucha reflexión, metaprogramación y los siempre agradecidos proxies dinámicos.
Un excelente ejemplo de DSL interno es el propio jMock.
Los DSL internos también son llamados "fluent interface" o "fluent API".

== Enlaces ==
[http://eamodeorubio.wordpress.com/2010/09/13/%C2%BFque-son-los-dsl-domain-specific-languages/ Fuente]

[[Selenium con DSL]]

[[Category: Diseño De Software]]

DSL

2011-04-26T18:23:32Z

Uva:

''Fuente: [http://eamodeorubio.wordpress.com/2010/09/13/%C2%BFque-son-los-dsl-domain-specific-languages/]''

== Qué son los DSL ==

DSL (Domain Specific Languages) se llama a cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas. Se diferencian de los lenguajes de programación, que están pensados para resolver cualquier tipo de problemas (lenguajes generalistas). Estos últimos, lo que suman en generalidad, también lo hacen en complejidad.

De esta forma nació el enfoque de los DSL, en vez de usar un lenguaje generalista, puedo usar diversos lenguajes de propósito específico, para resolver los diferentes problemas que surgen al implementar una aplicación. Por lo tanto sería muy eficiente contar con varios DSL, uno para cada tipo de problema con el que nos solemos encontrar, y para los problemas no tan típicos (los menos) solucionarlos con lenguajes generalistas.

Se utilizan DSL para resolver por ejemplo:
* Definición de interfaces de usuario
* Seguridad.
* Transacciones.
* Persistencia.
* Validación.
* Definición de tests automatizados

Ejemplos de DSL:
* SQL
* XML
* HTML
* CSS
* JSP

Existe un ciclo de vida en la evolución de una solución a un problema dentro del software. Primero resolvemos el problema como se nos ocurra. Después, conforme ganamos experiencia, al resolver el problema varias veces en contextos distintos, encontramos buenas prácticas o “recetas”, que nos permiten resolver el problema mediante copy/paste. En una etapa posterior de maduración, conseguimos abstraer esas recetas, en una librería que sigue un determinado diseño, y obtenemos un patrón de diseño al abstraer el diseño de la implementación en si. Una vez que tenemos varios patrones de diseño que resuelven distintos problemas de la misma categoría, podemos implementarlos juntos, y obtenemos un framework. Finalmente, y este es el paso menos conocido, el framework se hace cada vez más configurable y automatizado, con lo que éste termina evolucionando en un DSL.

== Tipos de DSL ==
Desde el punto de vista del tipo de problemas que resuelven, tenemos dos tipos de DSL, DSLs de negocio y DSLs técnicos. Sin embargo existe otra forma diferente de categorizar los DSLs, según el enfoque a la hora de implementarlos. De esta manera tenemos dos tipos:

=== DSLs externos ===
Un DSL externo es un lenguaje en si mismo, independiente de cualquier otro lenguaje. Posee su propia sintaxis, compilador y/o interprete, e incluso puede llegar a tener su propio IDE. Ejemplos de DSLs externos son SQL o ANTLR.
Los DSLs externos son el típico caso en el que uno piensa cuando se imagina un DSL, un lenguaje nuevo y aparte de los que ya existen.

=== DSLs internos ===
En este enfoque no construimos un lenguaje desde cero, sino que aprovechamos un lenguaje ya existente para construir nuestro DSL. Usando un poco de imaginación y exprimiendo los trucos del lenguaje anfitrión y su sintaxis, podemos construir una librería o framework que implemente el DSL de forma nativa al lenguaje anfitrión. Algunas técnicas usadas son los patrones “method chaining” y “builder”, el uso de métodos factoría estáticos, import estáticos, tipos y métodos paramétricos (genéricos) y por supuesto mucha reflexión, metaprogramación y los siempre agradecidos proxies dinámicos.
Un excelente ejemplo de DSL interno es el propio jMock.
Los DSL internos también son llamados "fluent interface" o "fluent API".

== Enlaces ==
[http://eamodeorubio.wordpress.com/2010/09/13/%C2%BFque-son-los-dsl-domain-specific-languages/ Fuente]

[[Selenium con DSL]]

[[Category: Diseño De Software]]

DSL

2011-04-26T18:22:54Z

Uva: /* Enlaces */

== Qué son los DSL ==

DSL (Domain Specific Languages) se llama a cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas. Se diferencian de los lenguajes de programación, que están pensados para resolver cualquier tipo de problemas (lenguajes generalistas). Estos últimos, lo que suman en generalidad, también lo hacen en complejidad.

De esta forma nació el enfoque de los DSL, en vez de usar un lenguaje generalista, puedo usar diversos lenguajes de propósito específico, para resolver los diferentes problemas que surgen al implementar una aplicación. Por lo tanto sería muy eficiente contar con varios DSL, uno para cada tipo de problema con el que nos solemos encontrar, y para los problemas no tan típicos (los menos) solucionarlos con lenguajes generalistas.

Se utilizan DSL para resolver por ejemplo:
* Definición de interfaces de usuario
* Seguridad.
* Transacciones.
* Persistencia.
* Validación.
* Definición de tests automatizados

Ejemplos de DSL:
* SQL
* XML
* HTML
* CSS
* JSP

Existe un ciclo de vida en la evolución de una solución a un problema dentro del software. Primero resolvemos el problema como se nos ocurra. Después, conforme ganamos experiencia, al resolver el problema varias veces en contextos distintos, encontramos buenas prácticas o “recetas”, que nos permiten resolver el problema mediante copy/paste. En una etapa posterior de maduración, conseguimos abstraer esas recetas, en una librería que sigue un determinado diseño, y obtenemos un patrón de diseño al abstraer el diseño de la implementación en si. Una vez que tenemos varios patrones de diseño que resuelven distintos problemas de la misma categoría, podemos implementarlos juntos, y obtenemos un framework. Finalmente, y este es el paso menos conocido, el framework se hace cada vez más configurable y automatizado, con lo que éste termina evolucionando en un DSL.

== Tipos de DSL ==
Desde el punto de vista del tipo de problemas que resuelven, tenemos dos tipos de DSL, DSLs de negocio y DSLs técnicos. Sin embargo existe otra forma diferente de categorizar los DSLs, según el enfoque a la hora de implementarlos. De esta manera tenemos dos tipos:

=== DSLs externos ===
Un DSL externo es un lenguaje en si mismo, independiente de cualquier otro lenguaje. Posee su propia sintaxis, compilador y/o interprete, e incluso puede llegar a tener su propio IDE. Ejemplos de DSLs externos son SQL o ANTLR.
Los DSLs externos son el típico caso en el que uno piensa cuando se imagina un DSL, un lenguaje nuevo y aparte de los que ya existen.

=== DSLs internos ===
En este enfoque no construimos un lenguaje desde cero, sino que aprovechamos un lenguaje ya existente para construir nuestro DSL. Usando un poco de imaginación y exprimiendo los trucos del lenguaje anfitrión y su sintaxis, podemos construir una librería o framework que implemente el DSL de forma nativa al lenguaje anfitrión. Algunas técnicas usadas son los patrones “method chaining” y “builder”, el uso de métodos factoría estáticos, import estáticos, tipos y métodos paramétricos (genéricos) y por supuesto mucha reflexión, metaprogramación y los siempre agradecidos proxies dinámicos.
Un excelente ejemplo de DSL interno es el propio jMock.
Los DSL internos también son llamados "fluent interface" o "fluent API".

== Enlaces ==
[http://eamodeorubio.wordpress.com/2010/09/13/%C2%BFque-son-los-dsl-domain-specific-languages/ Fuente]

[[Selenium con DSL]]

[[Category: Diseño De Software]]

DSL

2011-04-26T18:22:40Z

Uva: /* Enlaces */

== Qué son los DSL ==

DSL (Domain Specific Languages) se llama a cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas. Se diferencian de los lenguajes de programación, que están pensados para resolver cualquier tipo de problemas (lenguajes generalistas). Estos últimos, lo que suman en generalidad, también lo hacen en complejidad.

De esta forma nació el enfoque de los DSL, en vez de usar un lenguaje generalista, puedo usar diversos lenguajes de propósito específico, para resolver los diferentes problemas que surgen al implementar una aplicación. Por lo tanto sería muy eficiente contar con varios DSL, uno para cada tipo de problema con el que nos solemos encontrar, y para los problemas no tan típicos (los menos) solucionarlos con lenguajes generalistas.

Se utilizan DSL para resolver por ejemplo:
* Definición de interfaces de usuario
* Seguridad.
* Transacciones.
* Persistencia.
* Validación.
* Definición de tests automatizados

Ejemplos de DSL:
* SQL
* XML
* HTML
* CSS
* JSP

Existe un ciclo de vida en la evolución de una solución a un problema dentro del software. Primero resolvemos el problema como se nos ocurra. Después, conforme ganamos experiencia, al resolver el problema varias veces en contextos distintos, encontramos buenas prácticas o “recetas”, que nos permiten resolver el problema mediante copy/paste. En una etapa posterior de maduración, conseguimos abstraer esas recetas, en una librería que sigue un determinado diseño, y obtenemos un patrón de diseño al abstraer el diseño de la implementación en si. Una vez que tenemos varios patrones de diseño que resuelven distintos problemas de la misma categoría, podemos implementarlos juntos, y obtenemos un framework. Finalmente, y este es el paso menos conocido, el framework se hace cada vez más configurable y automatizado, con lo que éste termina evolucionando en un DSL.

== Tipos de DSL ==
Desde el punto de vista del tipo de problemas que resuelven, tenemos dos tipos de DSL, DSLs de negocio y DSLs técnicos. Sin embargo existe otra forma diferente de categorizar los DSLs, según el enfoque a la hora de implementarlos. De esta manera tenemos dos tipos:

=== DSLs externos ===
Un DSL externo es un lenguaje en si mismo, independiente de cualquier otro lenguaje. Posee su propia sintaxis, compilador y/o interprete, e incluso puede llegar a tener su propio IDE. Ejemplos de DSLs externos son SQL o ANTLR.
Los DSLs externos son el típico caso en el que uno piensa cuando se imagina un DSL, un lenguaje nuevo y aparte de los que ya existen.

=== DSLs internos ===
En este enfoque no construimos un lenguaje desde cero, sino que aprovechamos un lenguaje ya existente para construir nuestro DSL. Usando un poco de imaginación y exprimiendo los trucos del lenguaje anfitrión y su sintaxis, podemos construir una librería o framework que implemente el DSL de forma nativa al lenguaje anfitrión. Algunas técnicas usadas son los patrones “method chaining” y “builder”, el uso de métodos factoría estáticos, import estáticos, tipos y métodos paramétricos (genéricos) y por supuesto mucha reflexión, metaprogramación y los siempre agradecidos proxies dinámicos.
Un excelente ejemplo de DSL interno es el propio jMock.
Los DSL internos también son llamados "fluent interface" o "fluent API".

== Enlaces ==
[http://eamodeorubio.wordpress.com/2010/09/13/%C2%BFque-son-los-dsl-domain-specific-languages/ Fuente]
[[Selenium con DSL]]

[[Category: Diseño De Software]]

DSL

2011-04-26T18:22:29Z

Uva: /* Enlaces */

DSL

2011-04-26T18:22:13Z

Uva: /* Enlaces */

== Qué son los DSL ==

DSL (Domain Specific Languages) se llama a cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas. Se diferencian de los lenguajes de programación, que están pensados para resolver cualquier tipo de problemas (lenguajes generalistas). Estos últimos, lo que suman en generalidad, también lo hacen en complejidad.

De esta forma nació el enfoque de los DSL, en vez de usar un lenguaje generalista, puedo usar diversos lenguajes de propósito específico, para resolver los diferentes problemas que surgen al implementar una aplicación. Por lo tanto sería muy eficiente contar con varios DSL, uno para cada tipo de problema con el que nos solemos encontrar, y para los problemas no tan típicos (los menos) solucionarlos con lenguajes generalistas.

Se utilizan DSL para resolver por ejemplo:
* Definición de interfaces de usuario
* Seguridad.
* Transacciones.
* Persistencia.
* Validación.
* Definición de tests automatizados

Ejemplos de DSL:
* SQL
* XML
* HTML
* CSS
* JSP

Existe un ciclo de vida en la evolución de una solución a un problema dentro del software. Primero resolvemos el problema como se nos ocurra. Después, conforme ganamos experiencia, al resolver el problema varias veces en contextos distintos, encontramos buenas prácticas o “recetas”, que nos permiten resolver el problema mediante copy/paste. En una etapa posterior de maduración, conseguimos abstraer esas recetas, en una librería que sigue un determinado diseño, y obtenemos un patrón de diseño al abstraer el diseño de la implementación en si. Una vez que tenemos varios patrones de diseño que resuelven distintos problemas de la misma categoría, podemos implementarlos juntos, y obtenemos un framework. Finalmente, y este es el paso menos conocido, el framework se hace cada vez más configurable y automatizado, con lo que éste termina evolucionando en un DSL.

== Tipos de DSL ==
Desde el punto de vista del tipo de problemas que resuelven, tenemos dos tipos de DSL, DSLs de negocio y DSLs técnicos. Sin embargo existe otra forma diferente de categorizar los DSLs, según el enfoque a la hora de implementarlos. De esta manera tenemos dos tipos:

=== DSLs externos ===
Un DSL externo es un lenguaje en si mismo, independiente de cualquier otro lenguaje. Posee su propia sintaxis, compilador y/o interprete, e incluso puede llegar a tener su propio IDE. Ejemplos de DSLs externos son SQL o ANTLR.
Los DSLs externos son el típico caso en el que uno piensa cuando se imagina un DSL, un lenguaje nuevo y aparte de los que ya existen.

=== DSLs internos ===
En este enfoque no construimos un lenguaje desde cero, sino que aprovechamos un lenguaje ya existente para construir nuestro DSL. Usando un poco de imaginación y exprimiendo los trucos del lenguaje anfitrión y su sintaxis, podemos construir una librería o framework que implemente el DSL de forma nativa al lenguaje anfitrión. Algunas técnicas usadas son los patrones “method chaining” y “builder”, el uso de métodos factoría estáticos, import estáticos, tipos y métodos paramétricos (genéricos) y por supuesto mucha reflexión, metaprogramación y los siempre agradecidos proxies dinámicos.
Un excelente ejemplo de DSL interno es el propio jMock.
Los DSL internos también son llamados "fluent interface" o "fluent API".

== Enlaces ==
[http://eamodeorubio.wordpress.com/2010/09/13/%C2%BFque-son-los-dsl-domain-specific-languages/ Fuente]
[Selenium con DSL]

[[Category: Diseño De Software]]

DSL

2011-04-26T18:18:54Z

Uva:

DSL

2011-04-26T18:17:20Z

Uva: /* Tipos de DSL */

DSL

2011-04-26T18:02:16Z

Uva: /* Qué son los DSL */

== Qué son los DSL ==

DSL (Domain Specific Languages) se llama a cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas. Se diferencian de los lenguajes de programación, que están pensados para resolver cualquier tipo de problemas (lenguajes generalistas). Estos últimos, lo que suman en generalidad, también lo hacen en complejidad.

De esta forma nació el enfoque de los DSL, en vez de usar un lenguaje generalista, puedo usar diversos lenguajes de propósito específico, para resolver los diferentes problemas que surgen al implementar una aplicación. Por lo tanto sería muy eficiente contar con varios DSL, uno para cada tipo de problema con el que nos solemos encontrar, y para los problemas no tan típicos (los menos) solucionarlos con lenguajes generalistas.

Se utilizan DSL para resolver por ejemplo:
* Definición de interfaces de usuario
* Seguridad.
* Transacciones.
* Persistencia.
* Validación.
* Definición de tests automatizados

Ejemplos de DSL:
* SQL
* XML
* HTML
* CSS
* JSP

Existe un ciclo de vida en la evolución de una solución a un problema dentro del software. Primero resolvemos el problema como se nos ocurra. Después, conforme ganamos experiencia, al resolver el problema varias veces en contextos distintos, encontramos buenas prácticas o “recetas”, que nos permiten resolver el problema mediante copy/paste. En una etapa posterior de maduración, conseguimos abstraer esas recetas, en una librería que sigue un determinado diseño, y obtenemos un patrón de diseño al abstraer el diseño de la implementación en si. Una vez que tenemos varios patrones de diseño que resuelven distintos problemas de la misma categoría, podemos implementarlos juntos, y obtenemos un framework. Finalmente, y este es el paso menos conocido, el framework se hace cada vez más configurable y automatizado, con lo que éste termina evolucionando en un DSL.

== Tipos de DSL ==
Desde el punto de vista del tipo de problemas que resuelven, tenemos dos tipos de DSL, DSLs de negocio y DSLs técnicos. Sin embargo existe otra forma diferente de categorizar los DSLs, según el enfoque a la hora de implementarlos. De esta manera tenemos dos tipos:

DSLs externos. Un DSL externo es un lenguaje en si mismo, independiente de cualquier otro lenguaje. Posee su propia sintaxis, compilador y/o interprete, e incluso puede llegar a tener su propio IDE. Ejemplos de DSLs externos son SQL o ANTLR. Los DSLs externos son el típico caso en el que uno piensa cuando se imagina un DSL, un lenguaje nuevo y aparte de los que ya existen.
DSLs internos. En este enfoque no construimos un lenguaje desde cero, sino que aprovechamos un lenguaje ya existente para construir nuestro DSL. Usando un poco de imaginación y exprimiendo los trucos del lenguaje anfitrión y su sintaxis, podemos construir una librería o framework que implemente el DSL de forma nativa al lenguaje anfitrión. Algunas técnicas usadas son los patrones “method chaining” y “builder”, el uso de métodos factoría estáticos, import estáticos, tipos y métodos paramétricos (genéricos) y por supuesto mucha reflexión, metaprogramación y los siempre agradecidos proxies dinámicos. Un excelente ejemplo de DSL interno es el propio jMock. Los DSL internos también son llamados “fluent interface” o “fluent API”. Yo, pobre de mi, no sabía que existía esta denominación, por lo que se me ocurrió llamar “API Sexy” a un DSL que había construido, con el consiguiente cachondeo de mis compañeros.

[[Category: Diseño De Software]]

DSL

2011-04-26T17:58:02Z

Uva: /* Qué son los DSL */

DSL

2011-04-26T17:57:38Z

Uva: /* Qué son los DSL */

DSL

2011-04-26T17:57:15Z

Uva: /* Qué son los DSL */

DSL

2011-04-26T15:32:58Z

Uva: /* Qué son los DSL */

DSL

2011-04-26T15:19:49Z

Uva:

== Qué son los DSL ==

DSL (Domain Specific Languages) se llama a cualquier lenguaje que esté especializado en modelar o resolver un conjunto específico de problemas.

[[Category: Diseño De Software]]

DSL

2011-04-26T15:11:15Z

Uva: Página creada con 'Category: Diseño De Software'

[[Category: Diseño De Software]]

Diseño De Software

2011-04-26T15:10:51Z

Uva: /* Ver también */

El diseño de software es la tarea de representar en un lenguaje gráfico (usualmente [[UML]]) la solución de una problemática.

==¿Qué es el diseño?==

Supongo que todos, de una manera u otra, tenemos una idea de qué es diseñar: incluso quien menos cerca se encuentre de esta tarea sabe que, mínimamente, consiste en crear "cajitas con texto y muchas lineas" en alguna herramienta (electrónica o papel... muchos, me incluyo, empezamos sintiéndonos más cómodos con esta segunda opción; y es que a veces hasta resulta más facil pensar con un lapiz que con un mouse).

Pero más allá de las ideas y sensaciones que puedan tener internamente, el diseño es una actividad básicamente creativa: es pensar de cero cómo se resolverá un problema. Es crear, de manera aún más abstracta que en la programación, una solución intangible a un problema.

===Y el diseñador es...===

El diseñador será entonces, obviamente, la persona de comprender el problema e idear la mejor solución al mismo para que pueda ser resuelto por otras personas. El diseñador no resuelve el problema directamente, es decir, no se encarga de programarlo: le brinda a los desarrolladores la visión que tiene para una mejor solución de la situación.

Para poder comunicar su visión deberá, entonces, utilizar alguna herramienta para plasmar sus ideas (en la mente) en algo visible por personas que no posean poderes psíquicos. Actualmente, dicha herramienta se llama UML, y es un lenguaje visual que, con diagramas y notas, permite mostrar cómo un problema debe ser resuelto.

===Pero el diseñador no es...===

El diseñador no es el analista del problema: no puede suponer situaciones que no están explícitas en el caso de uso, ni es el experto en el área que tiene que resolver. Todas las dudas que tenga sobre el problema las deberá aclarar con el correspondiente analista, ya que él por si mismo no cuenta con los elementos necesarios para presuponer (adivinar) situaciones que le resulten confusas.

El diseñador tampoco es desarrollador... y esto, en nuestro ámbito, suele "doler" un poco. El diseñador se encuentra muy cerca del código y debe conocer la plataforma y arquitectura donde se implementará su solución (puede construir los castillos de arena que considere necesario... pero siempre dentro de un arenero que él mismo no construyó). Pero si bien conoce del código y lenguaje de implementación, insisto, el diseñador no es quien programará la solución.

Un buen diseñador debe conocer íntegramente la solución que quiere, y saber cómo quiere que se implemente en el lenguaje de turno. Por eso, personalmente pienso que un buen diseñador es, ante todo, un buen programador.

===Yo diseño, tu programas; yo programo, tu diseñas===

Esto último me parece importante destacar para no confudir: el rol del diseñador y desarrollador son distintos, y tienen responsabilidades distintas. Muchas veces tenemos la suerte de poder cumplir ambos roles (es decir, quienes diseñan algunas de las soluciones muchas veces participan luego directamente en la programación). Pero esta "dualidad" de roles no debe confundir las responsabilidades distintas que tienen. Al momento de diseño se deberá pensar que es otra persona quien deba entender nuestras ideas. Y como desarrolladores, debemos pedir (exigir!) diseños claros que nos ayuden y faciliten la tarea.

==Por qué diseñamos==

El objetivo del diseño es doble: construir aplicaciones en menor tiempo y con mayor calidad.

Pensar que se pierde tiempo diseñando es tener una visión muy pobre sobre la realidad: no se pierde tiempo en diseño, sino que se gana en construcción.

Un buen diseño permite crear sistemas de mayor calidad, mantenibles y escalables: nos permitirá programar aplicaciones más fáciles de entender por personas no involucradas, que sean flexibles para que puedan adaptarse a los cambios del negocio rápidamente. Esto permitirá que la aplicación pueda evolucionar junto al negocio con el menor esfuerzo posible.

Los problemas que aparecen al evitar (o escatimar) con la etapa de diseño son ampliamente conocidos y pueden leerse en varios libros, foros y notas. Y, obviamente como suele siempre pasar, a veces preferimos la "experiencia de primera mano"... cosa que también tenemos para contar. Tuvimos ya experiencias con proyectos donde la etapa de diseño fue, por diversos motivos, "relegada"... y sufrimos, a continuación, los problemas que todo librito avisa que siguen.

Aprendamos entonces de experiencias pasadas, evitando pegarnos repetidas veces contra la misma pared. Recordemos que el tiempo por si mismo no brinda experiencia, sino tan solo situaciones. Es nuestra capacidad de aprender de estas situaciones lo que lleva a la experiencia y nos enriquece como profesionales.

==El resultado de nuestro trabajo==

Evidentemente, los sistemas que creamos son la cara visible de nuestro equipo y el resultado de nuestro trabajo; es la manera y el producto por el cual nos conocen. Crear soluciones de calidad habla bien de nosotros como equipo; debemos apuntar constantemente a mejorarnos, utilizando las herramientas existentes para ayudarnos en este proceso de aprendizaje y superación constante.

== Ver también ==
* [[Diseño Por Contrato]]
* [[Patrones De Diseño]]
* [[Interfaces De Usuario]]
* [[UML]]
* [[DSL]]

[[Category: Diseño De Software]]

Stored Procedures con Hibernate

2010-06-29T13:56:43Z

Uva: /* Ver También */

Hibernate 3 nos da soporte para queries vía Stored Procedures (SP) y Funciones. El Stored Procedure o la función, deben devolver un ResultSet en el primer parámetro de salida para que Hibernate lo soporte.

== Reglas y limitaciones para el uso de Stored Procedures  ==

Hay ciertas reglas a respetar para que Hibernate funcione correctamente con los Stored Procedures. Si el mismo no respeta dichas reglas, se deberá ejecutar el Procedure vía session.connection().

*SP queries no pueden ser paginadas con setFirstResult()/setMaxResults().
*La llamada recomendada es la estandar SQL92: { ? = call functionName(<parameters>) } o { ? = call procedureName(<parameters>}. Las llamadas nativas no son soportadas.

Reglas que aplican para Oracle:

*Una function debe retornar un Result Set. El primer parámetro de un SP debe ser un OUT que devuelva el Result Set

 

== Ver También ==
[[Hibernate]] 
[http://docs.jboss.org/hibernate/stable/core/reference/en/html/querysql.html#sp_query Documentación de Hibernate con Stored Procedure]

Stored Procedures con Hibernate

2010-06-29T13:56:15Z

Uva: /* Ver También */

Hibernate 3 nos da soporte para queries vía Stored Procedures (SP) y Funciones. El Stored Procedure o la función, deben devolver un ResultSet en el primer parámetro de salida para que Hibernate lo soporte.

== Reglas y limitaciones para el uso de Stored Procedures  ==

Hay ciertas reglas a respetar para que Hibernate funcione correctamente con los Stored Procedures. Si el mismo no respeta dichas reglas, se deberá ejecutar el Procedure vía session.connection().

*SP queries no pueden ser paginadas con setFirstResult()/setMaxResults().
*La llamada recomendada es la estandar SQL92: { ? = call functionName(<parameters>) } o { ? = call procedureName(<parameters>}. Las llamadas nativas no son soportadas.

Reglas que aplican para Oracle:

*Una function debe retornar un Result Set. El primer parámetro de un SP debe ser un OUT que devuelva el Result Set

 

== Ver También ==
[[Hibernate]]
[http://docs.jboss.org/hibernate/stable/core/reference/en/html/querysql.html#sp_query Documentación de Hibernate con Stored Procedure]

Stored Procedures con Hibernate

2010-06-29T13:55:00Z

Uva: Página creada con 'Hibernate 3 nos da soporte para queries vía Stored Procedures (SP) y Funciones. El Stored Procedure o la función, deben devolver un ResultSet en el primer parámetro de salida…'

Hibernate 3 nos da soporte para queries vía Stored Procedures (SP) y Funciones. El Stored Procedure o la función, deben devolver un ResultSet en el primer parámetro de salida para que Hibernate lo soporte.

== Reglas y limitaciones para el uso de Stored Procedures  ==

Hay ciertas reglas a respetar para que Hibernate funcione correctamente con los Stored Procedures. Si el mismo no respeta dichas reglas, se deberá ejecutar el Procedure vía session.connection().

*SP queries no pueden ser paginadas con setFirstResult()/setMaxResults().
*La llamada recomendada es la estandar SQL92: { ? = call functionName(<parameters>) } o { ? = call procedureName(<parameters>}. Las llamadas nativas no son soportadas.

Reglas que aplican para Oracle:

*Una function debe retornar un Result Set. El primer parámetro de un SP debe ser un OUT que devuelva el Result Set

 

== Ver También ==
[http://docs.jboss.org/hibernate/stable/core/reference/en/html/querysql.html#sp_query Documentación de Hibernate con Stored Procedure]

Hibernate

2010-06-29T13:41:54Z

Uva: /* Ver también */

[[Category:Hibernate]]
Hibernate es un framework de persistencia de objetos para Java. Su función principal es la de [[Mapeo Objeto-Relacional]], es decir, mapear objetos a tablas de una base de datos relacional.

Actualmente Hibernate cuanta con varios subproyectos que resuelven distintos aspectos del acceso y manipulación de datos.

== Log de querys ==
Es posible decirle a Hibernate que realice un log de los comandos SQL que ejecuta. Esto resulta muy útil en tiempo de desarrollo.

Para esto es necesario definir la propiedad ''show_sql'' en la configuración de Hibernate (generalmente, el archivo ''hibernate.cfg.xml''):

<code xml>
<property name="show_sql">true</property>
</code>

Al ejecutar veremos algo como lo siguiente:

<code sql>
select emails0_.PERSON_ID as PERSON1_0_, emails0_.EMAIL_ADDR as EMAIL2_0_
from PERSONA emails0_
where emails0_.PERSON_ID=?
</code>

Si además queremos que el log aparezca mejor formateado, agregamos la variable ''format_sql'':

<code xml>
<property name="format_sql">true</property>
</code>

Y veremos:
<code sql>
select
emails0_.PERSON_ID as PERSON1_0_,
emails0_.EMAIL_ADDR as EMAIL2_0_
from
PERSONA emails0_
where
emails0_.PERSON_ID=?
</code>

Si ademas desean saber los valores de las bind variables, y variables de resultado que se utilizan en el query, deben configurar lo siguiente en el archivo ''log4j.properties'':

<code>
log4j.logger.org.hibernate.type=debug
</code>

Y veremos:
<code>
12:30:56,551 DEBUG LongType:133 - binding '1' to parameter: 1
12:30:56,551 DEBUG LongType:172 - returning '1' as column: PERSON1_0_
12:30:56,567 DEBUG StringType:172 - returning 'demo@dosideas.com' as column: EMAIL2_0_
</code>

Otra opción bastante interesante es ver el manejo de recursos por parte de Jdbc. Se debe agregar la propiedad:

<code>
log4j.logger.org.hibernate.jdbc=debug
</code>

Y veremos:

<code>
12:30:56,551 - opening JDBC connection
12:30:56,553 - preparing statement
12:30:56,554 - about to open ResultSet (open ResultSets: 0, globally: 0)
12:30:57,551 - about to close ResultSet (open ResultSets: 1, globally: 1)
12:30:58,551 - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
12:30:58,552 - closing statement
12:30:56,553 - aggressively releasing JDBC connection
12:30:56,554 - releasing JDBC connection [ (open PreparedStatements: 0, globally: 0)
(open ResultSets: 0, globally: 0)]
</code>

== Ver también ==
* [[Cache De Hibernate]]
* [[Hibernate Con Spring]]
* [[Hibernate Annotations con Spring]]
* [[Actualizacion Dinamica Con Hibernate]]
* [[Eficiencia Ejecutando Querys Con Hibernate]]
* [[Stored Procedures con Hibernate]]
* [http://www.hibernate.org/ Web oficial de Hibernate]
* [http://www.hibernate.org/hib_docs/v3/reference/en/html/tutorial.html#tutorial-firstapp Tutorial de Hibernate]
* [http://www.javaworld.com/javaworld/jw-07-2008/jw-07-orm-comparison.html Comparación entre Hibernate, iBatis y JPA]
* [http://www.dosideas.com/java/180-testeando-rapido-todos-los-mapeos-de-hibernate.html Testear todos los mapeos de Hibernate]

Stored Procedures con Spring

2010-06-28T19:50:13Z

Uva:

[[Spring Framework]] brinda una herramienta bastante práctica para invocar a [[Stored Procredures]] o funciones de forma de evitar el manejo de la conexión y facilitar el seteo de los parámetros.

== SimpleJdbcCall ==

Es una clase que provee Spring que representa la llamada a un stored procedure o store function. Se diferencia de cualquier otra clase utilitaria por leer la meta data de la base de datos, permitiendo que solo tengamos que pasarle en la invocación un map con los nombres de los parámetros y sus respectivos valores. No hace falta especificar los tipos de datos. Adicionalmente encapsula el manejo de la conexión y del statement (internamente usa otra clase mas genérica de Spring para JDBC llamada JdbcTemplate).

Como depende de la información que brinda la meta data, que es obtenida por el driver JDBC, las bases soportadas son Derby, MySQL, Microsoft SQL Server, Oracle y DB2.

=== Ejemplo invocación ===

<code java="java">
public class MiDao {

private SimpleJdbcCall miStoreProcedureCall;

public void buscarDireccion(String pametro1, String parametro2) {
SqlParameterSource mapIn = new MapSqlParameterSource()
.addValue("CODIGO_CLIENTE", pametro1)
.addValue("NUMERO_DOCUMENTO", parametro2);

Map<String, Object> out = getMiStoreProcedureCall().execute(mapIn);

String direccionCliente = (String) out.get("DIRECCION");

System.out.println("Invocacion exitosa. Direccion cliente: " + direccionCliente);
}
}
</code>

=== Ejemplo de invocacion a un procedure con cursor ===

Cuando invocamos un procedure que retorna un cursor podemos especificar a que tipo de dato queremos que nos convierta el resultado.

<code java="java">
public Collection<Linea> buscarLineasPorTitular(@NotNull Titular titular) {

SqlParameterSource parametrosPackage = new MapSqlParameterSource()
.addValue("P_TIPO_DOCUMENTO", titular.getTipoDocumento(), Types.VARCHAR)
.addValue("P_NUMERO_DOCUMENTO", titular.getNumeroDocumento().toString(), Types.VARCHAR);

Map<String, Object> out = getSimpleJdbcCall()
.withoutProcedureColumnMetaDataAccess()
.declareParameters(
new SqlParameter("P_TIPO_DOCUMENTO", Types.VARCHAR),
new SqlParameter("P_NUMERO_DOCUMENTO", Types.VARCHAR))
.returningResultSet("P_LINEAS", ParameterizedBeanPropertyRowMapper.newInstance(Linea.class))
.execute(parametrosPackage);

return (Collection<Linea>) out.get("P_LINEAS");
}
</code>

En este ejemplo seteamos que los datos del cursor(P_LINEAS) los convierta a la clase Linea y spring mapea los nombres de las columnas con los nombres de los atributos.

===== Por ejemplo: =====

-si el nombre de la columna es NUMERO_DOCUMENTO spring va a llamar a linea.setNumeroDocumento(..). -si el nombre de la columna es sistema spring va a llamar a linea.setSistema(..).

=== Configuración ===

En el ejemplo se decidió por inyectar la clase utilitaria, utilizando configuración en xml. De igual manera se podría haber hecho en el mismo código Java.

La clase SimpleJdbcCall necesita como parámetro del constructor el data source asociado a la base de datos en la cual se encuentra el store procedure.

En el ejemplo, el procedure se encuentra dentro de un package y de ahí una propiedad extra que hay que configurar (sino simplemente obviarla). Archivo xml:

<code xml="xml">
<beans>
<bean id="dataSourceApp" class="org.springframework.jndi.JndiObjectFactoryBean"
destroy-method="close">
<property name="jndiName" value="jdbc/miApp"/>
</bean>

<bean id="jdbc.miStoreP" class="org.springframework.jdbc.core.simple.SimpleJdbcCall">
<constructor-arg ref="dataSourceApp"/>
<property name="procedureName" value="BUSCAR_DIRECCION"/>
<property name="catalogName" value="PACKAGE_CLIENTES"/>
</bean>

<bean id="dao.MiDao" class="com.dosideas.MiDao">
<property name="miStoreProcedureCall" ref="jdbc.miStoreP"/>
</bean>
</beans>
</code>

== Schema ==

Como se menciono anteriormente, esta clase se basa en la obtención de la meta data. Para asegurarnos de que la obtenga correctamente debemos saber mas en detalle como la obtiene. Si corremos el ejemplo con un nivel de log en debug vamos a ver lo siguiente:

<code>
Retrieving metadata for PACKAGE_CLIENTES/SCHEMA/BUSCAR_DIRECCION
</code>

Si el dueño (owner) del package es diferente al del schema al cual nos estamos conectado, no va a poder obtener la meta data, aunque el mismo tenga un sinónimo publico. Lo importante es que Spring no da error en estos casos, sino que continua con la invocación. En nuestro caso seria algo del tipo:

<code>
Compiled stored procedure. Call string is [{call PACKAGE_CLIENTES.BUSCAR_DIRECCION()}]
</code>

Luego la base de datos nos dara un error indicando que estamos invocando al procedure con una cantidad incorrecta de parametros (ninguno), ocultado el error que origina todo esto.

Para solucionarlo basta con modificar la llamada al execute de SimpleJdbcCall de la siguiente forma:

<code java="java">
Map<String, Object> out = getMiStoreProcedureCall().withSchemaName("MI_ESQUEMA")
.execute(mapIn);
</code>

== Ver también ==

*[http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html#jdbc-simple-jdbc-call-1 Documentacion de spring con JDBC]

[[Category:Spring_Framework]] [[Category:Base_De_Datos]]

SoapUI Con JUnit

2010-06-24T14:25:07Z

Uva:

Es muy fácil incorporar la suite de test [[JUnit]] generada por [[SoapUI]] a nuestro proyecto y poder así sumar estos test a los test de integración de nuestra aplicación.

Librerias a incluir en el modulo de test de nuestro proyecto:

*bcprov-jdk15-138.jar
*commons-beanutils.jar
*commons-cli.jar
*commons-codec.jar
*commons-httpclient.jar
*not-yet-commons-ssl.jar
*soapui.jar
*soapui-xmlbeans.jar
*soap-xmlbeans.jar
*xbean-fixed.jar
*xmlpublic.jar

 De esta manera corremos la batería completa de test de un proyecto. Hay que tener en cuenta que al tener un solo test para toda la batería, cuando surge un error no se continúa con el resto de los test.

<code java="java">
@Test
public void holaMundo() throws Exception
{
SoapUITestCaseRunner runner = new SoapUITestCaseRunner();
runner.setProjectFile( "src/dist/HolaMundo-soapui-project.xml" );
runner.run();
}
</code>

También existe la posibilidad de correr individualmente cada uno de los test.

<code java="java">

WsdlProject wsdlProject = null;
TestSuite testSuite = null;

@Before
public void setUp() throws Exception {

wsdlProject = new WsdlProject("src/dist/HolaMundo-soapui-project.xml");
testSuite = wsdlProject.getTestSuiteByName("HolaMundo");
}

@Test
public void holaMundoOk() {

TestCase testCase = testSuite.getTestCaseByName("HolaMundoOk");
TestRunner runner = testCase.run(new PropertiesMap(), false);
assertEquals(Status.FINISHED, runner.getStatus());
}

@Test
public void holaMundoError() {

TestCase testCase = testSuite.getTestCaseByName("HolaMundoError");
TestRunner runner = testCase.run(new PropertiesMap(), false);
assertEquals(Status.FINISHED, runner.getStatus());
}

</code>

== Problemas con Assertions ==

Se presentan ciertos problemas al correr los test SoapUi con JUnit.

Soapui propone muchas formas para realizar assert sobre el response de un ws, a continuación un breve explicación de cada una:

*'''WS-security status''' : Chequea que el reponse tenga un encabezado ws-security válido.
*'''not soap fault''' : Chequea que el response no sea un fault.
*'''Response SLA''' : Chequea que el response haya tardado menos del tiempo configurado.
*'''SOAP response''': Chequea que el response sea un mensaje soap.
*'''Script assertion''': Permite hacer scrips de groovy para realizar assert con el response.
*'''WS adressing response''': Chequea que el encabezado del resopnse tenga propiedades válidas.
*'''Contains''': Chequea que el response contenga un valor o un tag con un valor determinado.
*'''Not Contains''': Chequea que el response no contenga un valor o un tag con un valor determinado.
*'''xQuery math''': Permite chequear el contenido del response con expresiones de xquery 2.0.
*'''Schema Compliance''': Chequea que el response sea compatible con un shema dado.
*'''xPath match''': Permite chquear el contenido del response con expresiones de xPath.
*'''Soap fault''': Chequea que el response sea un fault.

Estos assert son muy completos y muy fáciles de usar con el sopUI, pero una vez que guardamos un proyecto y lo importamos para correr los test de junit, los mismos fallan (retorna status FAILD). Entonces, para que los test corran automáticamente, vía junit, los únicos assert que se pueden hacer son los del tipo “contains” y “soap response”, cualquier otro tipo de assert falla. En principio con los contains se pueden hacer asserts sobre todo el response, pero tienen una serie de limitaciones: solo permite hacer assert por tag, es decir, que no se puede hacer un assert del xml completo, con lo cual si el xml del response tiene 20 tag, habrá que hacer 20 assert distintos. Otro punto en contra es que no hay un forma con las assertions para testeas los tags en el caso de que nuestro WebServices retorne una colección de datos, ya que es estos casos hace un assert sobre todo el xml, sin controlar la cantidad.

== Ver también ==

*[[Mock de un web service con Jetty|Alternativa a SoapUI utilizando Jetty]]
*[http://www.soapui.org/userguide/commandline/functional.html SoapUITestCaseRunner ]

[[Category:Web_Service]] [[Category:JUnit]]

SoapUI Con JUnit

2010-06-24T14:24:41Z

Uva:

SoapUI Con JUnit

2010-06-24T14:23:28Z

Uva:

Es muy fácil incorporar la suite de test [[JUnit]] generada por [[SoapUI]] a nuestro proyecto y poder así sumar estos test a los test de integración de nuestra aplicación.

Librerias a incluir en el modulo de test de nuestro proyecto:

*bcprov-jdk15-138.jar
*commons-beanutils.jar
*commons-cli.jar
*commons-codec.jar
*commons-httpclient.jar
*not-yet-commons-ssl.jar
*soapui.jar
*soapui-xmlbeans.jar
*soap-xmlbeans.jar
*xbean-fixed.jar
*xmlpublic.jar

 De esta manera corremos la batería completa de test de un proyecto. Hay que tener en cuenta que al tener un solo test para toda la batería, cuando surge un error no se continúa con el resto de los test.

<code java="java">
@Test
public void holaMundo() throws Exception
{
SoapUITestCaseRunner runner = new SoapUITestCaseRunner();
runner.setProjectFile( "src/dist/HolaMundo-soapui-project.xml" );
runner.run();
}
</code>

También existe la posibilidad de correr individualmente cada uno de los test.

<code java="java">

WsdlProject wsdlProject = null;
TestSuite testSuite = null;

@Before
public void setUp() throws Exception {

wsdlProject = new WsdlProject("src/dist/HolaMundo-soapui-project.xml");
testSuite = wsdlProject.getTestSuiteByName("HolaMundo");
}

@Test
public void holaMundoOk() {

TestCase testCase = testSuite.getTestCaseByName("HolaMundoOk");
TestRunner runner = testCase.run(new PropertiesMap(), false);
assertEquals(Status.FINISHED, runner.getStatus());
}

@Test
public void holaMundoError() {

TestCase testCase = testSuite.getTestCaseByName("HolaMundoError");
TestRunner runner = testCase.run(new PropertiesMap(), false);
assertEquals(Status.FINISHED, runner.getStatus());
}

</code>

== Problemas con Assertions ==

Se presentan ciertos problemas al correr los test SoapUi con JUnit.

Soapui propone muchas formas para realizar assert sobre el response de un ws, a continuación un breve explicación de cada una:

'''WS-security status''' : Chequea que el reponse tenga un encabezado ws-security válido.
'''not soap fault''' : Chequea que el response no sea un fault.
'''Response SLA''' : Chequea que el response haya tardado menos del tiempo configurado.
'''SOAP response''': Chequea que el response sea un mensaje soap.
'''Script assertion''': Permite hacer scrips de groovy para realizar assert con el response.
'''WS adressing response''': Chequea que el encabezado del resopnse tenga propiedades válidas.
'''Contains''': Chequea que el response contenga un valor o un tag con un valor determinado.
'''Not Contains''': Chequea que el response no contenga un valor o un tag con un valor determinado.
'''xQuery math''': Permite chequear el contenido del response con expresiones de xquery 2.0.
'''Schema Compliance''': Chequea que el response sea compatible con un shema dado.
'''xPath match''': Permite chquear el contenido del response con expresiones de xPath.
'''Soap fault''': Chequea que el response sea un fault.

Estos assert son muy completos y muy fáciles de usar con el sopUI, pero una vez que guardamos un proyecto y lo importamos para correr los test de junit, los mismos fallan (retorna status FAILD).
Entonces, para que los test corran automáticamente, vía junit, los únicos assert que se pueden hacer son los del tipo “contains” y “soap response”, cualquier otro tipo de assert falla.
En principio con los contains se pueden hacer asserts sobre todo el response, pero tienen una serie de limitaciones: solo permite hacer assert por tag, es decir, que no se puede hacer un assert del xml completo, con lo cual si el xml del response tiene 20 tag, habrá que hacer 20 assert distintos. Otro punto en contra es que no hay un forma con las assertions para testeas los tags en el caso de que nuestro WebServices retorne una colección de datos, ya que es estos casos hace un assert sobre todo el xml, sin controlar la cantidad.

== Ver también ==

*[[Mock_de_un_web_service_con_Jetty|Alternativa a SoapUI utilizando Jetty]]
*[http://www.soapui.org/userguide/commandline/functional.html SoapUITestCaseRunner ]

[[Category:Web_Service]] [[Category:JUnit]]

SoapUI Con JUnit

2010-06-24T14:22:12Z

Uva:

Es muy fácil incorporar la suite de test [[JUnit]] generada por [[SoapUI]] a nuestro proyecto y poder así sumar estos test a los test de integración de nuestra aplicación.

Librerias a incluir en el modulo de test de nuestro proyecto:

*bcprov-jdk15-138.jar
*commons-beanutils.jar
*commons-cli.jar
*commons-codec.jar
*commons-httpclient.jar
*not-yet-commons-ssl.jar
*soapui.jar
*soapui-xmlbeans.jar
*soap-xmlbeans.jar
*xbean-fixed.jar
*xmlpublic.jar

 De esta manera corremos la batería completa de test de un proyecto. Hay que tener en cuenta que al tener un solo test para toda la batería, cuando surge un error no se continúa con el resto de los test.

<code java="java">
@Test
public void holaMundo() throws Exception
{
SoapUITestCaseRunner runner = new SoapUITestCaseRunner();
runner.setProjectFile( "src/dist/HolaMundo-soapui-project.xml" );
runner.run();
}
</code>

También existe la posibilidad de correr individualmente cada uno de los test.

<code java="java">

WsdlProject wsdlProject = null;
TestSuite testSuite = null;

@Before
public void setUp() throws Exception {

wsdlProject = new WsdlProject("src/dist/HolaMundo-soapui-project.xml");
testSuite = wsdlProject.getTestSuiteByName("HolaMundo");
}

@Test
public void holaMundoOk() {

TestCase testCase = testSuite.getTestCaseByName("HolaMundoOk");
TestRunner runner = testCase.run(new PropertiesMap(), false);
assertEquals(Status.FINISHED, runner.getStatus());
}

@Test
public void holaMundoError() {

TestCase testCase = testSuite.getTestCaseByName("HolaMundoError");
TestRunner runner = testCase.run(new PropertiesMap(), false);
assertEquals(Status.FINISHED, runner.getStatus());
}

</code>

== Problemas con Assertions ==

Se presentan ciertos problemas al correr los test SoapUi con JUnit.

Soapui propone muchas formas para realizar assert sobre el response de un ws, a continuación un breve explicación de cada una:

'''WS-security status''' : Chequea que el reponse tenga un encabezado ws-security válido.
'''not soap fault''' : Chequea que el response no sea un fault.
'''Response SLA''' : Chequea que el response haya tardado menos del tiempo configurado.
'''SOAP response''': Chequea que el response sea un mensaje soap.
'''Script assertion''': Permite hacer scrips de groovy para realizar assert con el response.
'''WS adressing response''': Chequea que el encabezado del resopnse tenga propiedades válidas.
'''Contains''': Chequea que el response contenga un valor o un tag con un valor determinado.
'''Not Contains''': Chequea que el response no contenga un valor o un tag con un valor determinado.
'''xQuery math''': Permite chequear el contenido del response con expresiones de xquery 2.0.
'''Schema Compliance''': Chequea que el response sea compatible con un shema dado.
'''xPath match''': Permite chquear el contenido del response con expresiones de xPath.
'''Soap fault''': Chequea que el response sea un fault.

Estos assert son muy completos y muy fáciles de usar con el sopUI, pero una vez que guardamos un proyecto y lo importamos para correr los test de junit, los mismos fallan (retorna status FAILD).
Entonces, para que los test corran automáticamente, vía junit, los únicos assert que se pueden hacer son los del tipo “contains” y “soap response”, cualquier otro tipo de assert falla.
En principio con los contains se pueden hacer asserts sobre todo el response, pero tienen una serie de limitaciones: solo permite hacer assert por tag, es decir, que no se puede hacer un assert del xml completo, con lo cual si el xml del response tiene 20 tag, habrá que hacer 20 assert distintos. Otro punto en contra es que no hay un forma con las assertions para testeas los tags en el caso de que nuestro WebServices retorne una colección de datos, ya que es estos casos hace un assert sobre todo el xml, sin controlar la cantidad.

== Ver también ==

*[[Mock_de_un_web_service_con_Jetty|Alternativa a SoapUI utilizando Jetty]]
*[http://www.soapui.org/userguide/commandline/functional.html SoapUITestCaseRunner ]

[[Category:Web_Service]] [[Category:JUnit]]

Castor

2010-06-24T14:14:48Z

Uva:

[http://www.castor.org/ Castor] es un framework Open Source para Java, para transformaciones de Xml a Objetos Java y viceversa.

Es un gran herramienta para utilizar con [[Spring Web Services]], ya que se complementa mejor que otros frameworks (por ejemplo, XStream) a las definiciones de wsdl con Namespaces.

== Ver También ==
[http://www.castor.org/ Sitio Oficial de Castor]

Castor

2010-06-24T14:05:26Z

Uva:

[http://www.castor.org/ Castor]es un framework Open Source para Java, para transformaciones de Xml a Objetos Java y viceversa.

Es un gran herramienta para utilizar con [[Spring Web Services]], ya que se complementa mejor que otros frameworks (por ejemplo, XStream) a las definiciones de wsdl con Namespaces.

== Ver También ==
[http://www.castor.org/ Sitio Oficial de Castor]

Castor

2010-06-24T14:04:59Z

Uva:

[http://www.castor.org/ Castor]es un framework Open Source para Java, para transformaciones de Xml a Objetos Java y viceversa.

Es un gran herramienta para utilizar con [[Spring Web Services], ya que se complementa mejor que otros frameworks (por ejemplo, XStream) a las definiciones de wsdl con Namespaces.

== Ver También ==
[http://www.castor.org/ Sitio Oficial de Castor]

Castor

2010-06-24T14:00:14Z

Uva: Página creada con '[http://www.castor.org/ Castor] is an Open Source data binding framework for Java[tm]. It's the shortest path between Java objects, XML documents and relational tables. Castor p…'

[http://www.castor.org/ Castor] is an Open Source data binding framework for Java[tm]. It's the shortest path between Java objects, XML documents and relational tables. Castor provides Java-to-XML binding, Java-to-SQL persistence, and more.

Castor es un framework Open Source para Java, para transformaciones de Xml a Objetos Java y viceversa.

== Ver También ==
[http://www.castor.org/ Sitio Oficial de Castor]

Spring Web Services

2010-06-24T13:57:45Z

Uva:

[[Spring Web Services]] (Spring-WS) es un producto de [[Spring Framework]] para facilitar la creación de servicios web basados en el intercambio de documentos (document driven).

Spring-WS Se basa en servicios en los cuales primero se establece un contrato y luego se implementan (contract first), evitando atar al contrato como sucede en los casos en los cuales se genera el mismo a partir de las clases java.

{{curso|url=http://www.dosideas.com/cursos/course/view.php?id=10|nombre=Servicios Web con Spring-WS}}

==Las principales características de SpringWS==

Facilita aplicar las mejores practicas para la creación de servicios web
Facilidad para distribuir los pedidos xml a través de diferentes tipos de mapeos
Soporte para varias librerias de manejo de XML (DOM, SAX, StAX, JDOM, dom4j, XDOM)
Soporte para mapeo de xml a objetos ([[Castor]], JiBX, JAXB, XStream).

== Interceptores ==
Si usamos ''org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping'' para hacer el binding de los endpoints podemos agregar varios interceptores. Solo hay que definirlos dentro de la lista de interceptores que tiene como opción la clase.

Ejemplo:
<code xml>

<bean class="org.springframework.ws.server.endpoint.mapping.PayloadRootQNameEndpointMapping">
<property name="mappings">
<props>

<prop key="{http://dosideas.com/oc/schemas}OrdenDeCompraRequest">ordenDeCompraMarshallingEndPoint</prop>

<prop key="{http://dosideas.com/oc/schemas}ConsultaPrecioRequest">consultaPrecioMessageEndpoint</prop>
</props>
</property>
<property name="interceptors">
<list>
<bean class="org.springframework.ws.server.endpoint.interceptor.PayloadLoggingInterceptor"/>
<ref bean="validatingInterceptor"/>
</list>
</property>
</bean>
</code>

=== Interceptor de validaciones ===
El interceptor de validaciones es una herramienta muy útil, que nos permite verificar tanto el request como el response del web service. Verifica tanto el esquema de los xmls como las restricciones que tiene cada uno de los elementos de los xsd. Si alguna de las validaciones no se cumple devuelve un fault si es un request, y genera un warning en el log si es un response.

Ejemplo:
<code xml>
<bean id="validatingInterceptor"
class="org.springframework.ws.soap.server.endpoint.interceptor.PayloadValidatingInterceptor">
<property name="xsdSchemaCollection" ref="schemaCollection" />
<property name="validateRequest" value="true"/>
<property name="validateResponse" value="true"/>
</bean>
</code>
Este bean hace referencia a los esquemas(.xsd) y al interpretarlos puede saber la estructura y restricciones de los request/response.

Ejemplo:

<code xml>
<bean id="schemaCollection"
class="org.springframework.xml.xsd.commons.CommonsXsdSchemaCollection">
<property name="xsds">
<list>
<value>/WEB-INF/contratoDeDatos.xsd</value>
</list>
</property>
<property name="inline" value="true"/>
</bean>
</code>

Si el servicio tiene más de una operación, existirán varios xsd. Actualmente existe un error al querer ingresar más de un xsd(el interceptor ve solo el primero). Para salvar este error se aconseja generar un nuevo .xsd que incluya los definidos para cada operación.

Ejemplo de contratoDeDatos.xsd agrupador:

<code xml>
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.movistar.com.ar/ws/schema/cater"
elementFormDefault="qualified"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.movistar.com.ar/ws/schema/cater">

<xsd:include schemaLocation="validarCentroEmisor.xsd"></xsd:include>
<xsd:include schemaLocation="agenteUsuario.xsd"></xsd:include>
<xsd:include schemaLocation="validarFactura.xsd"></xsd:include>
</xsd:schema>
</code>

== Ver también ==
* [[MTOM con Spring Web Services]]
* [[Web Service Con Spring]]
* [http://www.dosideas.com/cursos/course/view.php?id=10 Curso de Spring-WS de DosIdeas]
* [http://static.springsource.org/spring-ws/sites/1.5/ Web oficial de Spring-WS]

[[Category:Spring Framework]]
[[Category:Web Service]]

SoapUI Con JUnit

2010-06-24T13:09:47Z

Uva:

Selenium

2009-11-02T20:09:56Z

Uva:

[[Selenium]] es una herramienta de [[Software Libre]] para pruebas de aplicaciones Web. Las pruebas de [[Selenium]] se ejecutan directamente en un navegador y facilitan las pruebas de compatibilidad en navegadores, también como pruebas funcionales de aceptación de aplicaciones Web.

La herramienta [[Selenium]] posee un ambiente de desarrollo llamado [[Selenium]] IDE, este facilita el registro de pruebas de aceptación y su depuración.

==Integracion con JUnit 4.x==

Para poder armar el test es necesario incluir los siguientes jars.

*selenium-java-client-driver-tests.jar
*selenium-java-client-driver.jar
*selenium-server-tests.jar
*selenium-server.jar

Se pueden descargar de acá: [http://archiva.openqa.org/repository/releases/org/openqa/selenium/selenium-remote-control/1.0-beta-1/selenium-remote-control-1.0-beta-1-dist.zip Librerías]

<code java>
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.server.SeleniumServer;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.SeleneseTestCase;

public class GoogleWebTest extends SeleneseTestCase {

private DefaultSelenium selenium;
private SeleniumServer seleniumServer;

@Override
@Before
public void setUp(String browser) throws Exception {
// Se instancia el server de selenium por default toma el puerto 4444
seleniumServer = new SeleniumServer();
seleniumServer.start();

// Se configura el acceso a la pagina por medio del server de selenium
// DefaultSelenium("SELENIUM_HOST", PUERTO, "BROWSER", URL_DE_LA_APLICACION);
// En este ejemplo, se utiliza Internet Explorer: "*iehta"
selenium = new DefaultSelenium("localhost", 4444, "*iehta", "http://www.google.com");
selenium.start();
}

/** Al finalizar los tests, detener el server de Selenium
*/
@Override
public void tearDown() throws Exception {
// Se para la conexión con la pagina
selenium.stop();

// Se para la instancia del server de selenium
seleniumServer.stop();
}

/** Testeamos una búsqueda en Google
* Accedemos a Google, realizamos una búsqueda y comprobamos que venga el resultado esperado
*/
@Test
public void testGoogle() throws Exception {
selenium.open("http://www.google.com/webhp");
assertEquals("Google", selenium.getTitle());
selenium.type("q", "Selenium OpenQA");
assertEquals("Selenium OpenQA", selenium.getValue("q"));
selenium.click("btnG");
selenium.waitForPageToLoad("30000");
assertEquals("Selenium OpenQA - Google Search", selenium.getTitle());
}

}
</code>

==Sobre waitForPageToLoad==

Es importante que la página esté cargada antes de hacer las verificaciones sobre el nuevo contenido. Para hacer más sólido el caso de prueba ubica un waitForPageToLoad luego de un click.

Es recomendable que al terminar un caso de prueba ubiques un waitForPageToLoad y así te aseguras que el próximo caso de prueba no falle al comenzar.

==Sobre assertTextNotPresent==

Este comando es útil después de cada comando clickAndWait para confirmar un texto no debe estar presente en la página.

==Sobre assertTextPresent==

Este comando es útil después de cada comando clickAndWait para confirmar un texto debe estar presente en la página.

== Sobre Popups ==

En Selenium, se trabaja con una ventana a la vez. Para trabajar con diferentes ventanas (por ejemplo, un popup) se necesita primero elegir la ventana en cuestión. Y no solo basta con esto, tambien dicha ventana tiene que ser identificada. La forma mas facil de realizar esto es capturar el id de la nueva ventana con Selenium IDE.

Si la ventana se abre con un target="_blank" no se podrá utilizar Selenium para acceder a dicha ventana dado a que el id que se genera es random. Hay un [http://jira.openqa.org/browse/SEL-203 Jira] abierto en Selenium para resolver esto.

==Ver también==
*[[Herramientas Para Pruebas De Aceptacion]]
*[http://selenium.openqa.org/ Web oficial de Selenium]
*[http://www.pghcodingdojo.org/index.php/Selenium_RC_Tutorial Selenium RC Tutorial]
*[http://www.dosideas.com/java/743-test-secuencial-con-selenium-y-junit.html Test Secuancial con Selenium y JUnit]
*[http://wiki.openqa.org/display/SEL/Selenium+Core+FAQ#SeleniumCoreFAQ-HowdoIworkwithapopupwindow%3F Popup con Selenium]

[[Category:ATDD]]

Selenium

2009-11-02T20:07:18Z

Uva: /* Sobre Popups */

[[Selenium]] es una herramienta de [[Software Libre]] para pruebas de aplicaciones Web. Las pruebas de [[Selenium]] se ejecutan directamente en un navegador y facilitan las pruebas de compatibilidad en navegadores, también como pruebas funcionales de aceptación de aplicaciones Web.

La herramienta [[Selenium]] posee un ambiente de desarrollo llamado [[Selenium]] IDE, este facilita el registro de pruebas de aceptación y su depuración.

==Integracion con JUnit 4.x==

Para poder armar el test es necesario incluir los siguientes jars.

*selenium-java-client-driver-tests.jar
*selenium-java-client-driver.jar
*selenium-server-tests.jar
*selenium-server.jar

Se pueden descargar de acá: [http://archiva.openqa.org/repository/releases/org/openqa/selenium/selenium-remote-control/1.0-beta-1/selenium-remote-control-1.0-beta-1-dist.zip Librerías]

<code java>
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.server.SeleniumServer;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.SeleneseTestCase;

public class GoogleWebTest extends SeleneseTestCase {

private DefaultSelenium selenium;
private SeleniumServer seleniumServer;

@Override
@Before
public void setUp(String browser) throws Exception {
// Se instancia el server de selenium por default toma el puerto 4444
seleniumServer = new SeleniumServer();
seleniumServer.start();

// Se configura el acceso a la pagina por medio del server de selenium
// DefaultSelenium("SELENIUM_HOST", PUERTO, "BROWSER", URL_DE_LA_APLICACION);
// En este ejemplo, se utiliza Internet Explorer: "*iehta"
selenium = new DefaultSelenium("localhost", 4444, "*iehta", "http://www.google.com");
selenium.start();
}

/** Al finalizar los tests, detener el server de Selenium
*/
@Override
public void tearDown() throws Exception {
// Se para la conexión con la pagina
selenium.stop();

// Se para la instancia del server de selenium
seleniumServer.stop();
}

/** Testeamos una búsqueda en Google
* Accedemos a Google, realizamos una búsqueda y comprobamos que venga el resultado esperado
*/
@Test
public void testGoogle() throws Exception {
selenium.open("http://www.google.com/webhp");
assertEquals("Google", selenium.getTitle());
selenium.type("q", "Selenium OpenQA");
assertEquals("Selenium OpenQA", selenium.getValue("q"));
selenium.click("btnG");
selenium.waitForPageToLoad("30000");
assertEquals("Selenium OpenQA - Google Search", selenium.getTitle());
}

}
</code>

==Sobre waitForPageToLoad==

Es importante que la página esté cargada antes de hacer las verificaciones sobre el nuevo contenido. Para hacer más sólido el caso de prueba ubica un waitForPageToLoad luego de un click.

Es recomendable que al terminar un caso de prueba ubiques un waitForPageToLoad y así te aseguras que el próximo caso de prueba no falle al comenzar.

==Sobre assertTextNotPresent==

Este comando es útil después de cada comando clickAndWait para confirmar un texto no debe estar presente en la página.

==Sobre assertTextPresent==

Este comando es útil después de cada comando clickAndWait para confirmar un texto debe estar presente en la página.

== Sobre Popups ==

En Selenium, se trabaja con una ventana a la vez. Para trabajar con diferentes ventanas (por ejemplo, un popup) se necesita primero elegir la ventana en cuestión. Y no solo basta con esto, tambien dicha ventana tiene que ser identificada. La forma mas facil de realizar esto es capturar el id de la nueva ventana con Selenium IDE.

Si la ventana se abre con un target="_blank" no se podrá utilizar Selenium para acceder a dicha ventana.

==Ver también==
*[[Herramientas Para Pruebas De Aceptacion]]
*[http://selenium.openqa.org/ Web oficial de Selenium]
*[http://www.pghcodingdojo.org/index.php/Selenium_RC_Tutorial Selenium RC Tutorial]
*[http://www.dosideas.com/java/743-test-secuencial-con-selenium-y-junit.html Test Secuancial con Selenium y JUnit]
*[http://wiki.openqa.org/display/SEL/Selenium+Core+FAQ#SeleniumCoreFAQ-HowdoIworkwithapopupwindow%3F Popup con Selenium]

[[Category:ATDD]]