Hoy vamos a ver principalmente como hacer pruebas unitarias y de integración para la capa de acceso a datos, DAO, en una aplicación de JPA. Pero también veremos otros aspectos interesantes sobre pruebas que impliquen BBDD, como puede ser el uso de librerías para la creación de un contexto JNDI hasta incluso BBDD para pruebas.
Para empezar debemos aclarar un poco que son los test unitarios y que son los test de integración, con la ayuda de estas versiones resumidas de su definición:
- Test Unitario: Es aquel destinado a probar un único componente del código. El cual se puede ejecutar sin necesidad de otras dependencias.
- Test de Integración: Es aquel destinado a probar una funcionalidad compleja del código. Implicará la iteración entre distintos componentes e inclusos con sistemas externos al código.
Otro de los puntos a tener en cuenta, es que los test serán sobre tecnología de Jakarta EE y no con Spring. Por lo que serán un poco más elaborados. Además cuando queramos realizar los tests de integración diferenciaremos entre si queremos utilizar una conexión JDBC o acceder a la BBDD a través de JNDI. Esta última solución será aplicable a otros tipos de tests que necesiten del acceso a través de JNDI, de hay que hagamos un ejemplo diferente para probar lo mismo.
Empezaremos creando la clase Entity que será un reflejo de una tabla que tenemos en la BBDD.
@Data @Entity @Table(name = "BOOK") @NamedQuery(name = "Book.findAll", query = "SELECT b FROM Book b") public class Book { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Integer id; private String name; private String author; }
El siguiente paso será crear nuestra clase de acceso a datos. Esta parte la realizaremos en dos pasos. Primero crearemos una clase abstracta y genérica que contenga los métodos comunes. Esta clase implementará una interfaz que es la que declarará los métodos que tiene.
public abstract class GenericDaoImpl<K, E> implements GenericDao<K, E> { private Class<E> persistentClass; @SuppressWarnings("unchecked") public GenericDaoImpl() { Type genericSuperClass = getClass().getGenericSuperclass(); ParameterizedType parametrizedType = null; while (parametrizedType == null) { if (genericSuperClass instanceof ParameterizedType) { parametrizedType = (ParameterizedType) genericSuperClass; } else { genericSuperClass = ((Class<?>) genericSuperClass).getGenericSuperclass(); } } this.persistentClass = (Class<E>) parametrizedType.getActualTypeArguments()[1]; } @Override public List<E> findAll() { return getEntityManager().createNamedQuery(
String.format("%s.findAll", persistentClass.getSimpleName()),
persistentClass).getResultList(); } @Override public E getByField(final String field, final String value) { return getEntityManager()
.createQuery(
String.format("SELECT t FROM %s t where t.%s = :value",
persistentClass.getSimpleName(), field), persistentClass)
.setParameter("value", value).getResultStream().findFirst().orElse(null); } @Override public E getById(final K key) { return getEntityManager().find(persistentClass, key); } }
A continuación crearemos la clase de acceso a datos asociada a nuestra entidad. La cual extenderá la clase anterior y además se le incluirá la dependencia de la clase EntityManager, la cual nos permitirá acceder propiamente a los datos.
@Stateless public class BookDaoImpl extends GenericDaoImpl<Integer, Book> { @PersistenceContext(unitName = "persistence-unit") protected EntityManager em; @Override public EntityManager getEntityManager() { return em; } }
Esta clase será identificada como un componente sin estado a ser gestionado por el servidor a través de la anotación @Stateless, la cual también nos permitirá inyectarla en otras clases. Aparte le será inyectada la clase EntityManager, cuyo comportamiento es definido en el fichero META-INF/persistence.xml y que nos dará el acceso a la BBDD y la gestión de transacciones.
Empecemos ya con los ejemplos. Primero irá el test unitario, donde no necesitaremos ninguna BBDD o proveedor de persistencia. Verificaremos el funcionamiento de los métodos a través de mocks. Por tanto, estas serán las únicas librerías que necesitemos:
- La especificación de Java EE: javax.javaee-api.
- Librerías propias de Testing: Junit para los tests, Hamcrest para las verificaciones y Mockito para la simulación de objetos.
@ExtendWith(MockitoExtension.class) public class GenericDaoImplUnitTest { BookDaoImpl dao; @Mock EntityManager eManager; @Mock TypedQuery<Book> mockQuery; private List<Book> _getBooks() { List<Book> lst = new ArrayList<Book>(); lst.add(new Book()); return lst; } @Test public void findAll() { when(dao.em.createNamedQuery(ArgumentMatchers.anyString(), ArgumentMatchers.eq(Book.class)))
.thenReturn(mockQuery);
when(mockQuery.getResultList()).thenReturn(_getBooks()); List<Book> lst = dao.findAll(); assertEquals(1, lst.size()); verify(dao.em).createNamedQuery("Book.findAll", Book.class); } @BeforeEach public void setUp() { dao = new BookDaoImpl(); dao.em = eManager; } }
Estos métodos verificarán el correcto funcionamiento. Pero no podremos testear el funcionamiento del propio EntityManager, su configuración, o en caso de consultas más complejas si están correctamente desarrolladas. Por todo ello realizaremos a continuación un ejemplo de test de integración, en cual nos conectaremos a una BBDD, probando de esta forma la configuración y funcionamiento real de las consultas.
Para poder llevar a cabo este tipo de pruebas, necesitaremos las siguientes librerías:
- Un proveedor de persistencia, es decir la implementación de la API de JPA. En este caso utilizaremos org.eclipse.persistence.eclipselink.
- Una base de datos. Para nuestro ejemplo usaremos com.h2database.h2.
<?xml version="1.0" encoding="UTF-8"?> <persistence version="2.2" xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_2.xsd"> <persistence-unit name="persistence-unit-test" transaction-type="RESOURCE_LOCAL"> <class>com.home.example.dbjunittest.entity.Book</class> <properties> <property name="javax.persistence.jdbc.url"
value="jdbc:h2:mem:test:sample;DB_CLOSE_ON_EXIT=FALSE;INIT=RUNSCRIPT FROM 'classpath:schema-generator.sql';" />
<property name="javax.persistence.jdbc.driver" value="org.h2.Driver" /> <property name="javax.persistence.schema-generation.database.action" value="none" /> <property name="eclipselink.logging.level.sql" value="FINE"/> <property name="eclipselink.logging.parameters" value="true"/>
</properties> </persistence-unit> </persistence>
Y a continuación elaboraremos nuestro test de integración que hará uso de esta configuración.
public class BookDaoImplITTest { private static BookDaoImpl dao; @BeforeAll public static void before() { dao = new BookDaoImpl(); EntityManagerFactory emf = Persistence.createEntityManagerFactory("persistence-unit-test"); dao.em = emf.createEntityManager(); } @Test public void findAll() { List<Book> lst = dao.findAll(); assertThat(lst.size(), equalTo(1)); }}
Ahora veremos una modificación de este último ejemplo, utilizando en vez de una conexión JDBC, una conexión a través de JNDI. Pero para ello tendremos que añadir una nueva librería: com.github.h-thurow.simple-jndi. Esta librería nos permitirá poblar al objeto InitialContext con un Datasource que nosotros indiquemos, para que así pueda ser utilizado por el Entity Manager.
El primer paso en este nuevo ejemplo es modificar el fichero persistence.xml, para indicar que dejamos de utilizar una conexión JDBC y queremos usar una JNDI.
<persistence-unit name="persistence-unit-test" transaction-type="RESOURCE_LOCAL"> <non-jta-data-source>java:comp/env/jdbc/myds</non-jta-data-source> <class>com.home.example.jpajndiinttest.entity.Book</class> <properties> <property name="javax.persistence.jdbc.driver" value="org.h2.Driver" /> <property name="javax.persistence.schema-generation.database.action" value="none" /> <property name="eclipselink.logging.level.sql" value="FINE"/> <property name="eclipselink.logging.parameters" value="true"/> </properties> </persistence-unit>
Para que la carga del Datasource en el contexto funcione correctamente debemos configurar dos ficheros. Uno será el encargado de configurar la librería que hemos indicado a través de un fichero denominado jndi.properties. En el aparte de configuración propia de la librería, indicaremos los caracteres de separación para la nomenclatura, el espacio de almacenaje de dicha información, y donde se ubicarán los ficheros para los distintos objetos a crear.
java.naming.factory.initial=org.osjava.sj.SimpleContextFactory org.osjava.sj.jndi.shared=true org.osjava.sj.delimiter=. jndi.syntax.separator=/ org.osjava.sj.space=java:comp/envorg.osjava.sj.root=src/test/resources/jndi
El segundo fichero, será el que configure el Datasource y en base a lo indicado anteriormente debe cumplir las siguientes reglas y contenido:
- Debe estar almacenado en la carpeta src/test/resources/jndi
- Debe llamarse jdbc.properties
- Cada una de las propiedades del Datasource deben tener el sufijo myds.
myds.type=javax.sql.DataSource myds.driver=org.h2.Driver myds.url=jdbc:h2:mem:test:sample;DB_CLOSE_ON_EXIT=FALSE;INIT=RUNSCRIPT FROM 'classpath:schema-generator.sql'; myds.user=sa myds.password=password
Ya solo nos quedará realizar el test de la siguiente forma:
public class BookDaoImplIT { static BookDaoImpl dao; static InitialContext initContext; @BeforeAll public static void setup() throws Exception { initContext = new InitialContext(); dao = new BookDaoImpl(); EntityManagerFactory emf = Persistence.createEntityManagerFactory("persistence-unit-test"); dao.em = emf.createEntityManager(); } @Test public void findAll() throws InterruptedException { List<Book> lst = dao.findAll(); assertThat(lst.size(), equalTo(1)); } }
Debemos tener en cuenta que ambos ejemplos no gestionan las transacciones al ser de tipo local. Por lo que si queremos hacer ejemplos más complejos, deberemos gestionar las transacciones manualmente. Esto es debido a que si utilizamos conexiones JTA, la clase EntityManagerFactory no funcionará.
Indicar también que si queremos ejecutar los este tipo en una fase posterior o de forma independiente, también lo podemos hacer. Para ello tendremos que utilizar maven-failsafe-plugin. Y deberemos seguir las siguientes instrucciones:
- El test debe seguir el siguiente patrón: "**/IT*.java, **/*IT.java o **/*ITCase.java
- Debemos asociar su ejecución a una de las fases del ciclo de vida de Maven.
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-failsafe-plugin</artifactId> <version>2.22.2</version> <executions> <execution> <goals> <goal>integration-test</goal> </goals> </execution> </executions> </plugin>
Como veis no solo hemos aprendido a hacer tests a la capa de acceso a datos sino que por el camino hemos aprendido un par detalles interesantes. Además, en el enlace al código fuente, podréis ver un test de cada uno los métodos para los distintos ejemplos, aquí.
